From netconf-bounces@ietf.org Tue Aug 5 05:05:58 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944183A6D04; Tue, 5 Aug 2008 05:05:58 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61ADC28C232 for ; Tue, 5 Aug 2008 05:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_05=-1.11, 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 nkjdnGwIZEyV for ; Tue, 5 Aug 2008 05:05:56 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 32FD13A6BB1 for ; Tue, 5 Aug 2008 05:05:56 -0700 (PDT) Received: (qmail 95346 invoked from network); 5 Aug 2008 12:06:05 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 5 Aug 2008 12:06:05 -0000 Message-ID: <9A317CA138C54659B5A7B4E3B959CB5E@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Tue, 5 Aug 2008 14:05:13 +0200 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18000 Subject: [Netconf] Pls volunteer for NOMCOM X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org WG members, pls consider volunteering! Bert and Mehmet ----- Original Message ----- From: "NomCom Chair" To: "Working Group Chairs" Sent: Sunday, August 03, 2008 4:43 PM Subject: Please ask your WG... > To volunteer for the nomcom. > The nomcom process is (in my opinion) better served by a large pool of > volunteers drawn from a wide spectrum of IETF attendees. > As such, please ask on your individual mailing lists for folks to > volunteer. > > Obviously, the exact method for doing so is up to you. > The most recent call for volunteers can be reference here: > https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1617 > Whether you copy that message, or reference is probably up to you and the > habits of your working group mailing list. > If you want to reference or copy the status message I sent out, that can > be found at: > https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1618 > > Thank you, > Joel M. Halpern > Nomcom Chair > jmh@joelahlpern.com > nomcom-chair@ietf.org > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Aug 5 05:05:58 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944183A6D04; Tue, 5 Aug 2008 05:05:58 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61ADC28C232 for ; Tue, 5 Aug 2008 05:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_05=-1.11, 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 nkjdnGwIZEyV for ; Tue, 5 Aug 2008 05:05:56 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 32FD13A6BB1 for ; Tue, 5 Aug 2008 05:05:56 -0700 (PDT) Received: (qmail 95346 invoked from network); 5 Aug 2008 12:06:05 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 5 Aug 2008 12:06:05 -0000 Message-ID: <9A317CA138C54659B5A7B4E3B959CB5E@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Tue, 5 Aug 2008 14:05:13 +0200 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18000 Subject: [Netconf] Pls volunteer for NOMCOM X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org WG members, pls consider volunteering! Bert and Mehmet ----- Original Message ----- From: "NomCom Chair" To: "Working Group Chairs" Sent: Sunday, August 03, 2008 4:43 PM Subject: Please ask your WG... > To volunteer for the nomcom. > The nomcom process is (in my opinion) better served by a large pool of > volunteers drawn from a wide spectrum of IETF attendees. > As such, please ask on your individual mailing lists for folks to > volunteer. > > Obviously, the exact method for doing so is up to you. > The most recent call for volunteers can be reference here: > https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1617 > Whether you copy that message, or reference is probably up to you and the > habits of your working group mailing list. > If you want to reference or copy the status message I sent out, that can > be found at: > https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1618 > > Thank you, > Joel M. Halpern > Nomcom Chair > jmh@joelahlpern.com > nomcom-chair@ietf.org > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 7 14:12:39 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C69B43A6A08; Thu, 7 Aug 2008 14:12:39 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69A1D28C192 for ; Thu, 7 Aug 2008 14:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.242 X-Spam-Level: X-Spam-Status: No, score=0.242 tagged_above=-999 required=5 tests=[AWL=-0.093, 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 hLfQb-6dr3ZX for ; Thu, 7 Aug 2008 14:12:37 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id AF0E33A6819 for ; Thu, 7 Aug 2008 14:12:34 -0700 (PDT) Received: (qmail 65209 invoked from network); 7 Aug 2008 21:12:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 7 Aug 2008 21:12:26 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <489B6539.20307@netconfcentral.com> Date: Thu, 07 Aug 2008 14:12:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETCONF Subject: [Netconf] XML element order X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Is the NETCONF agent allowed to accept XML elements out of the specified order? It does not seem to break anything. This rule seems to be an XML CLR which violates the Postel Principle. SNMP never had a specified order for individual var-binds. The CLI does not enforce any (sibling) command order either. A NETCONF database does not even have a canonical ordering. Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 7 14:12:39 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C69B43A6A08; Thu, 7 Aug 2008 14:12:39 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69A1D28C192 for ; Thu, 7 Aug 2008 14:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.242 X-Spam-Level: X-Spam-Status: No, score=0.242 tagged_above=-999 required=5 tests=[AWL=-0.093, 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 hLfQb-6dr3ZX for ; Thu, 7 Aug 2008 14:12:37 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id AF0E33A6819 for ; Thu, 7 Aug 2008 14:12:34 -0700 (PDT) Received: (qmail 65209 invoked from network); 7 Aug 2008 21:12:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 7 Aug 2008 21:12:26 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <489B6539.20307@netconfcentral.com> Date: Thu, 07 Aug 2008 14:12:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETCONF Subject: [Netconf] XML element order X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Is the NETCONF agent allowed to accept XML elements out of the specified order? It does not seem to break anything. This rule seems to be an XML CLR which violates the Postel Principle. SNMP never had a specified order for individual var-binds. The CLI does not enforce any (sibling) command order either. A NETCONF database does not even have a canonical ordering. Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 7 14:19:00 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A9A28C1B2; Thu, 7 Aug 2008 14:19:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8095928C1B2 for ; Thu, 7 Aug 2008 14:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.191 X-Spam-Level: X-Spam-Status: No, score=-1.191 tagged_above=-999 required=5 tests=[AWL=0.855, 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 35PKyK8X-AuU for ; Thu, 7 Aug 2008 14:18:58 -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 B1CE328C1A8 for ; Thu, 7 Aug 2008 14:18:58 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 554B876C4CB; Thu, 7 Aug 2008 23:18:58 +0200 (CEST) Date: Thu, 07 Aug 2008 23:18:56 +0200 (CEST) Message-Id: <20080807.231856.142574379.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <489B6539.20307@netconfcentral.com> References: <489B6539.20307@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] XML element order X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > Hi, > > Is the NETCONF agent allowed to accept XML elements > out of the specified order? Do you mean inside the protocol or inside the data? > It does not seem to > break anything. This rule seems to be an XML CLR > which violates the Postel Principle. This is an interesting question. The protocol is defined with an XSD which specifies an order of the XML elements. One of the main arguments for using XML and XSD has always been that one can use existing tools. But existing XML tools are not liberal. For example, they will not accept a missing namespace or that some elements are out of order. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 7 14:19:00 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A9A28C1B2; Thu, 7 Aug 2008 14:19:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8095928C1B2 for ; Thu, 7 Aug 2008 14:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.191 X-Spam-Level: X-Spam-Status: No, score=-1.191 tagged_above=-999 required=5 tests=[AWL=0.855, 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 35PKyK8X-AuU for ; Thu, 7 Aug 2008 14:18:58 -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 B1CE328C1A8 for ; Thu, 7 Aug 2008 14:18:58 -0700 (PDT) Received: from localhost (217-211-56-90-no38.tbcn.telia.com [217.211.56.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 554B876C4CB; Thu, 7 Aug 2008 23:18:58 +0200 (CEST) Date: Thu, 07 Aug 2008 23:18:56 +0200 (CEST) Message-Id: <20080807.231856.142574379.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <489B6539.20307@netconfcentral.com> References: <489B6539.20307@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] XML element order X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > Hi, > > Is the NETCONF agent allowed to accept XML elements > out of the specified order? Do you mean inside the protocol or inside the data? > It does not seem to > break anything. This rule seems to be an XML CLR > which violates the Postel Principle. This is an interesting question. The protocol is defined with an XSD which specifies an order of the XML elements. One of the main arguments for using XML and XSD has always been that one can use existing tools. But existing XML tools are not liberal. For example, they will not accept a missing namespace or that some elements are out of order. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 7 14:31:43 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58FCF3A6933; Thu, 7 Aug 2008 14:31:43 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37DF3A68CE for ; Thu, 7 Aug 2008 14:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzdlj7Y6IxRG for ; Thu, 7 Aug 2008 14:31:41 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id F114D3A6933 for ; Thu, 7 Aug 2008 14:31:40 -0700 (PDT) Received: (qmail 9251 invoked from network); 7 Aug 2008 21:31:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 7 Aug 2008 21:31:39 -0000 X-YMail-OSG: 37qSFd4VM1kp7zTYMbeB_ayXTTjHtk5EvtB8iX_TKarSAP1dIigcLUHz3hgzAIK0nzkJoGkF7XWg9LE5NX2es52jitIBjQIDkFO7MQFJ7w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489B69BA.9080500@netconfcentral.com> Date: Thu, 07 Aug 2008 14:31:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <489B6539.20307@netconfcentral.com> <20080807.231856.142574379.mbj@tail-f.com> In-Reply-To: <20080807.231856.142574379.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] XML element order X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Is the NETCONF agent allowed to accept XML elements >> out of the specified order? > > Do you mean inside the protocol or inside the data? > both >> It does not seem to >> break anything. This rule seems to be an XML CLR >> which violates the Postel Principle. > > This is an interesting question. The protocol is defined with an XSD > which specifies an order of the XML elements. One of the main > arguments for using XML and XSD has always been that one can use > existing tools. But existing XML tools are not liberal. For example, > they will not accept a missing namespace or that some elements are out > of order. > Show me an 'off-the-shelf' XML tool that generates elements compliant with RFC 4741, or one with 'virtual nodes' that facilitates sub-agent implementation. I suppose an implementation could gather all its distributed data into one giant XML document for processing with such tools. Implementation details should not matter that much to the IETF. And what about agents that go fishing in any namespace if the manager does not specify any? Clearly broken wrt/ XML, but clearly useful trying to get some useful work done. I should let the manager tell the agent "I don't care if you ignore out-of-order errors, but I don't. It's done with a CLI flag on the agent. This is the difference between 'with-defaults' and let the agent do whatever they want wrt/ defaults. It is OK if the manager says in the PDU "I do not want you to follow the filtering rules exactly. I want you to leave out the defaults." The agent should only be non-compliant on demand :-) > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 7 14:31:43 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58FCF3A6933; Thu, 7 Aug 2008 14:31:43 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37DF3A68CE for ; Thu, 7 Aug 2008 14:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzdlj7Y6IxRG for ; Thu, 7 Aug 2008 14:31:41 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id F114D3A6933 for ; Thu, 7 Aug 2008 14:31:40 -0700 (PDT) Received: (qmail 9251 invoked from network); 7 Aug 2008 21:31:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 7 Aug 2008 21:31:39 -0000 X-YMail-OSG: 37qSFd4VM1kp7zTYMbeB_ayXTTjHtk5EvtB8iX_TKarSAP1dIigcLUHz3hgzAIK0nzkJoGkF7XWg9LE5NX2es52jitIBjQIDkFO7MQFJ7w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489B69BA.9080500@netconfcentral.com> Date: Thu, 07 Aug 2008 14:31:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <489B6539.20307@netconfcentral.com> <20080807.231856.142574379.mbj@tail-f.com> In-Reply-To: <20080807.231856.142574379.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] XML element order X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Is the NETCONF agent allowed to accept XML elements >> out of the specified order? > > Do you mean inside the protocol or inside the data? > both >> It does not seem to >> break anything. This rule seems to be an XML CLR >> which violates the Postel Principle. > > This is an interesting question. The protocol is defined with an XSD > which specifies an order of the XML elements. One of the main > arguments for using XML and XSD has always been that one can use > existing tools. But existing XML tools are not liberal. For example, > they will not accept a missing namespace or that some elements are out > of order. > Show me an 'off-the-shelf' XML tool that generates elements compliant with RFC 4741, or one with 'virtual nodes' that facilitates sub-agent implementation. I suppose an implementation could gather all its distributed data into one giant XML document for processing with such tools. Implementation details should not matter that much to the IETF. And what about agents that go fishing in any namespace if the manager does not specify any? Clearly broken wrt/ XML, but clearly useful trying to get some useful work done. I should let the manager tell the agent "I don't care if you ignore out-of-order errors, but I don't. It's done with a CLI flag on the agent. This is the difference between 'with-defaults' and let the agent do whatever they want wrt/ defaults. It is OK if the manager says in the PDU "I do not want you to follow the filtering rules exactly. I want you to leave out the defaults." The agent should only be non-compliant on demand :-) > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 7 14:45:18 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9643A6AA4; Thu, 7 Aug 2008 14:45:13 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70B33A67B3 for ; Thu, 7 Aug 2008 14:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=0.627, 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 3l0+HUTm-yjY for ; Thu, 7 Aug 2008 14:45:06 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 8E4EC3A6A5B for ; Thu, 7 Aug 2008 14:45:06 -0700 (PDT) Received: (qmail 53026 invoked from network); 7 Aug 2008 21:45:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 7 Aug 2008 21:45:04 -0000 X-YMail-OSG: T5iSnMQVM1lIilB1ehay539dA9gswxQ5HxWy1MP4nP1nbE1M_26ky1CQcAwynDcmS2RU0Spe0i0a81EPD67EnU.eIdRUi.PtxDSke0xHTw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489B6CDE.5020005@netconfcentral.com> Date: Thu, 07 Aug 2008 14:45:02 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <489B6539.20307@netconfcentral.com> <20080807.231856.142574379.mbj@tail-f.com> In-Reply-To: <20080807.231856.142574379.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] XML element order X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Is the NETCONF agent allowed to accept XML elements >> out of the specified order? > > Do you mean inside the protocol or inside the data? > Inside the data, a leaf-list is sensitive to order. There is of course the CLR about encoding list keys first, as well. (My agent has to generate an error even if it does not care if the key leaf is first?) Obviously ordered-by user lists and leaf-lists are sensitive to element order as well. I already have code to make the agent as robust and bullet-proof as possible. It seems dumb to add code to make the agent as picky as possible. This is a OPS-NM no-no. >> It does not seem to >> break anything. This rule seems to be an XML CLR >> which violates the Postel Principle. > > This is an interesting question. The protocol is defined with an XSD > which specifies an order of the XML elements. One of the main > arguments for using XML and XSD has always been that one can use > existing tools. But existing XML tools are not liberal. For example, > they will not accept a missing namespace or that some elements are out > of order. > > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/liFrom netconf-bounces@ietf.org Thu Aug 7 14:45:18 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9643A6AA4; Thu, 7 Aug 2008 14:45:13 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70B33A67B3 for ; Thu, 7 Aug 2008 14:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=0.627, 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 3l0+HUTm-yjY for ; Thu, 7 Aug 2008 14:45:06 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 8E4EC3A6A5B for ; Thu, 7 Aug 2008 14:45:06 -0700 (PDT) Received: (qmail 53026 invoked from network); 7 Aug 2008 21:45:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 7 Aug 2008 21:45:04 -0000 X-YMail-OSG: T5iSnMQVM1lIilB1ehay539dA9gswxQ5HxWy1MP4nP1nbE1M_26ky1CQcAwynDcmS2RU0Spe0i0a81EPD67EnU.eIdRUi.PtxDSke0xHTw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489B6CDE.5020005@netconfcentral.com> Date: Thu, 07 Aug 2008 14:45:02 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <489B6539.20307@netconfcentral.com> <20080807.231856.142574379.mbj@tail-f.com> In-Reply-To: <20080807.231856.142574379.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] XML element order X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Is the NETCONF agent allowed to accept XML elements >> out of the specified order? > > Do you mean inside the protocol or inside the data? > Inside the data, a leaf-list is sensitive to order. There is of course the CLR about encoding list keys first, as well. (My agent has to generate an error even if it does not care if the key leaf is first?) Obviously ordered-by user lists and leaf-lists are sensitive to element order as well. I already have code to make the agent as robust and bullet-proof as possible. It seems dumb to add code to make the agent as picky as possible. This is a OPS-NM no-no. >> It does not seem to >> break anything. This rule seems to be an XML CLR >> which violates the Postel Principle. > > This is an interesting question. The protocol is defined with an XSD > which specifies an order of the XML elements. One of the main > arguments for using XML and XSD has always been that one can use > existing tools. But existing XML tools are not liberal. For example, > they will not accept a missing namespace or that some elements are out > of order. > > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfostinfo/netconf /netconf From netconf-bounces@ietf.org Fri Aug 8 01:28:39 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 520763A6CD4; Fri, 8 Aug 2008 01:28:39 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4FEF3A6C9A; Fri, 8 Aug 2008 01:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+ZLZ4VpMW1R; Fri, 8 Aug 2008 01:28:37 -0700 (PDT) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id 144A23A6CCD; Fri, 8 Aug 2008 01:28:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id 6DCD33BF5F; Fri, 8 Aug 2008 10:28:00 +0200 (CEST) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30565-01-90; Fri, 8 Aug 2008 10:28:00 +0200 (CEST) Received: from wl-eduroam-50-246.publik.su.se (wl-eduroam-50-246.publik.su.se [77.238.33.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id 03BF93BE22; Fri, 8 Aug 2008 10:27:59 +0200 (CEST) From: Leif Johansson To: netconf@ietf.org Date: Fri, 8 Aug 2008 10:27:58 +0200 User-Agent: KMail/1.9.9 References: <489B6539.20307@netconfcentral.com> <20080807.231856.142574379.mbj@tail-f.com> In-Reply-To: <20080807.231856.142574379.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808081027.58888.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se Cc: netmod@ietf.org Subject: Re: [Netconf] XML element order X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Thursday 07 August 2008 23:18:56 Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, Sorry for cross-posting this but this is probably critically important for netmod wg too... > > > > Is the NETCONF agent allowed to accept XML elements > > out of the specified order? > > Do you mean inside the protocol or inside the data? > I think this question may be related to the question I asked at the mic in Dublin about the uniqueness of representation of a yang model in xml form. A necessary (but probably not sufficient) requirement that since yang lists are order-preserving the corresponging xml representation needs to be order-preserving too. It is absolutely critical for yang that there is a *unique* mapping between yang and xml since yang uses xpath. Cheers Leif _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 8 01:28:39 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 520763A6CD4; Fri, 8 Aug 2008 01:28:39 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4FEF3A6C9A; Fri, 8 Aug 2008 01:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+ZLZ4VpMW1R; Fri, 8 Aug 2008 01:28:37 -0700 (PDT) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id 144A23A6CCD; Fri, 8 Aug 2008 01:28:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id 6DCD33BF5F; Fri, 8 Aug 2008 10:28:00 +0200 (CEST) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30565-01-90; Fri, 8 Aug 2008 10:28:00 +0200 (CEST) Received: from wl-eduroam-50-246.publik.su.se (wl-eduroam-50-246.publik.su.se [77.238.33.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id 03BF93BE22; Fri, 8 Aug 2008 10:27:59 +0200 (CEST) From: Leif Johansson To: netconf@ietf.org Date: Fri, 8 Aug 2008 10:27:58 +0200 User-Agent: KMail/1.9.9 References: <489B6539.20307@netconfcentral.com> <20080807.231856.142574379.mbj@tail-f.com> In-Reply-To: <20080807.231856.142574379.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808081027.58888.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se Cc: netmod@ietf.org Subject: Re: [Netconf] XML element order X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Thursday 07 August 2008 23:18:56 Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, Sorry for cross-posting this but this is probably critically important for netmod wg too... > > > > Is the NETCONF agent allowed to accept XML elements > > out of the specified order? > > Do you mean inside the protocol or inside the data? > I think this question may be related to the question I asked at the mic in Dublin about the uniqueness of representation of a yang model in xml form. A necessary (but probably not sufficient) requirement that since yang lists are order-preserving the corresponging xml representation needs to be order-preserving too. It is absolutely critical for yang that there is a *unique* mapping between yang and xml since yang uses xpath. Cheers Leif _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 8 01:48:59 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 114493A6B45; Fri, 8 Aug 2008 01:48:59 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293133A6B45 for ; Fri, 8 Aug 2008 01:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RooHgbCBmPJ0 for ; Fri, 8 Aug 2008 01:48:57 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4CDC43A6963 for ; Fri, 8 Aug 2008 01:48:57 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 31CF020BEE; Fri, 8 Aug 2008 10:48:56 +0200 (CEST) X-AuditID: c1b4fb3c-ad0ccbb0000015b5-26-489c08786a3e Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 19D5A206F7; Fri, 8 Aug 2008 10:48:56 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 10:48:55 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 10:48:55 +0200 Message-ID: <489BFEB1.407@ericsson.com> Date: Fri, 08 Aug 2008 10:07:13 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <489B6539.20307@netconfcentral.com> In-Reply-To: <489B6539.20307@netconfcentral.com> X-OriginalArrivalTime: 08 Aug 2008 08:48:55.0435 (UTC) FILETIME=[9722D5B0:01C8F933] X-Brightmail-Tracker: AAAAAA== Cc: NETCONF Subject: Re: [Netconf] XML element order X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > Hi, > > Is the NETCONF agent allowed to accept XML elements > out of the specified order? It does not seem to > break anything. This rule seems to be an XML CLR > which violates the Postel Principle. AFAIK the Postel principle states that you should be strict in what you send. So at least for sending the draft should still mandate the order. It is up to the receiving side to accept a free order even if it is, strictly speaking, non-compliant. On the other hand the receiver might also reject it. Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 8 01:48:59 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 114493A6B45; Fri, 8 Aug 2008 01:48:59 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293133A6B45 for ; Fri, 8 Aug 2008 01:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RooHgbCBmPJ0 for ; Fri, 8 Aug 2008 01:48:57 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4CDC43A6963 for ; Fri, 8 Aug 2008 01:48:57 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 31CF020BEE; Fri, 8 Aug 2008 10:48:56 +0200 (CEST) X-AuditID: c1b4fb3c-ad0ccbb0000015b5-26-489c08786a3e Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 19D5A206F7; Fri, 8 Aug 2008 10:48:56 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 10:48:55 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 10:48:55 +0200 Message-ID: <489BFEB1.407@ericsson.com> Date: Fri, 08 Aug 2008 10:07:13 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <489B6539.20307@netconfcentral.com> In-Reply-To: <489B6539.20307@netconfcentral.com> X-OriginalArrivalTime: 08 Aug 2008 08:48:55.0435 (UTC) FILETIME=[9722D5B0:01C8F933] X-Brightmail-Tracker: AAAAAA== Cc: NETCONF Subject: Re: [Netconf] XML element order X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > Hi, > > Is the NETCONF agent allowed to accept XML elements > out of the specified order? It does not seem to > break anything. This rule seems to be an XML CLR > which violates the Postel Principle. AFAIK the Postel principle states that you should be strict in what you send. So at least for sending the draft should still mandate the order. It is up to the receiving side to accept a free order even if it is, strictly speaking, non-compliant. On the other hand the receiver might also reject it. Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 8 02:18:26 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA913A6CEB; Fri, 8 Aug 2008 02:18:26 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25B763A6CE4; Fri, 8 Aug 2008 02:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RP6-boqSFHk6; Fri, 8 Aug 2008 02:18:24 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 191583A6CC3; Fri, 8 Aug 2008 02:18:24 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 48A9D203D1; Fri, 8 Aug 2008 11:18:23 +0200 (CEST) X-AuditID: c1b4fb3c-ae8cfbb0000015b5-d7-489c0f5f953b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 26C71209A5; Fri, 8 Aug 2008 11:18:23 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 11:18:22 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 11:18:22 +0200 Message-ID: <489C0F56.6030801@ericsson.com> Date: Fri, 08 Aug 2008 11:18:14 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund , "Ersue, Mehmet (NSN - DE/Muenich)" , Bert Wijnen - IETF References: <489B310A.5070802@andybierman.com> <20080807.220904.108338659.mbj@tail-f.com> In-Reply-To: <20080807.220904.108338659.mbj@tail-f.com> X-OriginalArrivalTime: 08 Aug 2008 09:18:22.0389 (UTC) FILETIME=[B4529E50:01C8F937] X-Brightmail-Tracker: AAAAAA== Cc: David Partain , netconf mailing list , netmod@ietf.org Subject: Re: [Netconf] [netmod] leaf encoding rules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: >> A NETCONF server that replies to a or request MAY >> choose not to send the leaf element if its value is the default >> value. Thus, a client that receives an for a or >> request, must be prepared to handle the case that a leaf >> node with a default value is not present in the XML. In this case, >> the value used by the server is known to be the default value. >> >> >> I strongly object to this paragraph. >> It has no place in the YANG specification. >> If you want to modify the NETCONF operations, >> then do it in the NETCONF WG. > > I don't agree that the NETCONF operation is changed. rfc4741 does not > say one way or the other re. defaults. NETCONF has no concept of > default values. > > The intention of this paragraph is to allow a capability such as > 'with-defaults' to control if defaults are sent or not. IMO it is > better to keep this paragraph - if we remove it people will not know > if defaults should always be sent or what the intention of YANG was. > Esp. since there is no standard 'with-defaults' capability, and it > does not seem that it will get standardized any time soon. > Maybe we should get with-defaults standardized. I hereby ask the NETCONF/NETMOD community and specially the chairs of NETCONF if they would accept as a new NETCONF work item a small draft adding a with-defaults option to Netconf as a capability. As my Partial locking draft seems to wind down (Is this wishful thinking :-) I might even volunteer to write a draft on with-defaults. Opinions? Good idea? Feasible idea? Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 8 02:18:26 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA913A6CEB; Fri, 8 Aug 2008 02:18:26 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25B763A6CE4; Fri, 8 Aug 2008 02:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RP6-boqSFHk6; Fri, 8 Aug 2008 02:18:24 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 191583A6CC3; Fri, 8 Aug 2008 02:18:24 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 48A9D203D1; Fri, 8 Aug 2008 11:18:23 +0200 (CEST) X-AuditID: c1b4fb3c-ae8cfbb0000015b5-d7-489c0f5f953b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 26C71209A5; Fri, 8 Aug 2008 11:18:23 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 11:18:22 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 11:18:22 +0200 Message-ID: <489C0F56.6030801@ericsson.com> Date: Fri, 08 Aug 2008 11:18:14 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund , "Ersue, Mehmet (NSN - DE/Muenich)" , Bert Wijnen - IETF References: <489B310A.5070802@andybierman.com> <20080807.220904.108338659.mbj@tail-f.com> In-Reply-To: <20080807.220904.108338659.mbj@tail-f.com> X-OriginalArrivalTime: 08 Aug 2008 09:18:22.0389 (UTC) FILETIME=[B4529E50:01C8F937] X-Brightmail-Tracker: AAAAAA== Cc: David Partain , netconf mailing list , netmod@ietf.org Subject: Re: [Netconf] [netmod] leaf encoding rules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: >> A NETCONF server that replies to a or request MAY >> choose not to send the leaf element if its value is the default >> value. Thus, a client that receives an for a or >> request, must be prepared to handle the case that a leaf >> node with a default value is not present in the XML. In this case, >> the value used by the server is known to be the default value. >> >> >> I strongly object to this paragraph. >> It has no place in the YANG specification. >> If you want to modify the NETCONF operations, >> then do it in the NETCONF WG. > > I don't agree that the NETCONF operation is changed. rfc4741 does not > say one way or the other re. defaults. NETCONF has no concept of > default values. > > The intention of this paragraph is to allow a capability such as > 'with-defaults' to control if defaults are sent or not. IMO it is > better to keep this paragraph - if we remove it people will not know > if defaults should always be sent or what the intention of YANG was. > Esp. since there is no standard 'with-defaults' capability, and it > does not seem that it will get standardized any time soon. > Maybe we should get with-defaults standardized. I hereby ask the NETCONF/NETMOD community and specially the chairs of NETCONF if they would accept as a new NETCONF work item a small draft adding a with-defaults option to Netconf as a capability. As my Partial locking draft seems to wind down (Is this wishful thinking :-) I might even volunteer to write a draft on with-defaults. Opinions? Good idea? Feasible idea? Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 8 02:55:39 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803BB3A6CA9; Fri, 8 Aug 2008 02:55:39 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 771D03A6CA9 for ; Fri, 8 Aug 2008 02:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=0.418, 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 XLJp8nsiQ5TS for ; Fri, 8 Aug 2008 02:55:38 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 5F8443A6CA7 for ; Fri, 8 Aug 2008 02:55:38 -0700 (PDT) Received: (qmail 2249 invoked from network); 8 Aug 2008 09:48:58 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 8 Aug 2008 09:48:56 -0000 X-YMail-OSG: zvXXqgUVM1k3mg3m7eLBN4MMC08VG_4RUsR_lEKUjU4QuzTP0QSsm.RFRJTH__Exkr_5IAzlzjqqJLglJqVWeq37SrhGM1hZ3W4xLHW7_WzuCYUMF6dE3LsRGoN6Frw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489C1686.8000607@netconfcentral.com> Date: Fri, 08 Aug 2008 02:48:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Balazs Lengyel References: <489B310A.5070802@andybierman.com> <20080807.220904.108338659.mbj@tail-f.com> <489C0F56.6030801@ericsson.com> In-Reply-To: <489C0F56.6030801@ericsson.com> Cc: netmod@ietf.org, netconf mailing list Subject: Re: [Netconf] [netmod] leaf encoding rules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel wrote: > > > Martin Bjorklund wrote: >>> A NETCONF server that replies to a or request MAY >>> choose not to send the leaf element if its value is the default >>> value. Thus, a client that receives an for a or >>> request, must be prepared to handle the case that a >>> leaf >>> node with a default value is not present in the XML. In this case, >>> the value used by the server is known to be the default value. >>> >>> >>> I strongly object to this paragraph. >>> It has no place in the YANG specification. >>> If you want to modify the NETCONF operations, >>> then do it in the NETCONF WG. >> >> I don't agree that the NETCONF operation is changed. rfc4741 does not >> say one way or the other re. defaults. NETCONF has no concept of >> default values. >> >> The intention of this paragraph is to allow a capability such as >> 'with-defaults' to control if defaults are sent or not. IMO it is >> better to keep this paragraph - if we remove it people will not know >> if defaults should always be sent or what the intention of YANG was. >> Esp. since there is no standard 'with-defaults' capability, and it >> does not seem that it wiFrom netconf-bounces@ietf.org Fri Aug 8 02:55:39 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803BB3A6CA9; Fri, 8 Aug 2008 02:55:39 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 771D03A6CA9 for ; Fri, 8 Aug 2008 02:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=0.418, 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 XLJp8nsiQ5TS for ; Fri, 8 Aug 2008 02:55:38 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 5F8443A6CA7 for ; Fri, 8 Aug 2008 02:55:38 -0700 (PDT) Received: (qmail 2249 invoked from network); 8 Aug 2008 09:48:58 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 8 Aug 2008 09:48:56 -0000 X-YMail-OSG: zvXXqgUVM1k3mg3m7eLBN4MMC08VG_4RUsR_lEKUjU4QuzTP0QSsm.RFRJTH__Exkr_5IAzlzjqqJLglJqVWeq37SrhGM1hZ3W4xLHW7_WzuCYUMF6dE3LsRGoN6Frw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489C1686.8000607@netconfcentral.com> Date: Fri, 08 Aug 2008 02:48:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Balazs Lengyel References: <489B310A.5070802@andybierman.com> <20080807.220904.108338659.mbj@tail-f.com> <489C0F56.6030801@ericsson.com> In-Reply-To: <489C0F56.6030801@ericsson.com> Cc: netmod@ietf.org, netconf mailing list Subject: Re: [Netconf] [netmod] leaf encoding rules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel wrote: > > > Martin Bjorklund wrote: >>> A NETCONF server that replies to a or request MAY >>> choose not to send the leaf element if its value is the default >>> value. Thus, a client that receives an for a or >>> request, must be prepared to handle the case that a >>> leaf >>> node with a default value is not present in the XML. In this case, >>> the value used by the server is known to be the default value. >>> >>> >>> I strongly object to this paragraph. >>> It has no place in the YANG specification. >>> If you want to modify the NETCONF operations, >>> then do it in the NETCONF WG. >> >> I don't agree that the NETCONF operation is changed. rfc4741 does not >> say one way or the other re. defaults. NETCONF has no concept of >> default values. >> >> The intention of this paragraph is to allow a capability such as >> 'with-defaults' to control if defaults are sent or not. IMO it is >> better to keep this paragraph - if we remove it people will not know >> if defaults should always be sent or what the intention of YANG was. >> Esp. since there is no standard 'with-defaults' capability, and it >> does not seem thatll get standardized any time soon. >> > > Maybe we should get with-defaults standardized. > > I hereby ask the NETCONF/NETMOD community and specially the chairs of > NETCONF if they would accept as a new NETCONF work item a small draft > adding a with-defaults option to Netconf as a capability. As my Partial > locking draft seems to wind down (Is this wishful thinking :-) I might > even volunteer to write a draft on with-defaults. > You mean something like this: http://tools.ietf.org/html/draft-bierman-ncx-ext-00 I would be interested in pulling out just the with-defaults and republishing this draft. IMO, a capability is overkill, but if an agent wants to suppress defaults unless explicitly requested to send them, that should be OK, as long as there is a status flag the manager can retrieve that indicates this is how the agent works. > Opinions? Good idea? Feasible idea? > > Balazs Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf it will get standardized any time soon. >> > > Maybe we should get with-defaults standardized. > > I hereby ask the NETCONF/NETMOD community and specially the chairs of > NETCONF if they would accept as a new NETCONF work item a small draft > adding a with-defaults option to Netconf as a capability. As my Partial > locking draft seems to wind down (Is this wishful thinking :-) I might > even volunteer to write a draft on with-defaults. > You mean something like this: http://tools.ietf.org/html/draft-bierman-ncx-ext-00 I would be interested in pulling out just the with-defaults and republishing this draft. IMO, a capability is overkill, but if an agent wants to suppress defaults unless explicitly requested to send them, that should be OK, as long as there is a status flag the manager can retrieve that indicates this is how the agent works. > Opinions? Good idea? Feasible idea? > > Balazs Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 8 03:13:25 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBAAA3A687F; Fri, 8 Aug 2008 03:13:24 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C143A6967; Fri, 8 Aug 2008 03:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56FkErNHIZrF; Fri, 8 Aug 2008 03:13:22 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9AC5E3A6D25; Fri, 8 Aug 2008 03:12:24 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B817620030; Fri, 8 Aug 2008 12:12:23 +0200 (CEST) X-AuditID: c1b4fb3c-ad8cdbb0000015b5-12-489c1c077c25 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 97AC120535; Fri, 8 Aug 2008 12:12:23 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 12:12:23 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 12:12:23 +0200 Message-ID: <489C1BFF.70707@ericsson.com> Date: Fri, 08 Aug 2008 12:12:15 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <489B310A.5070802@andybierman.com> <20080807.220904.108338659.mbj@tail-f.com> <489C0F56.6030801@ericsson.com> <489C1686.8000607@netconfcentral.com> In-Reply-To: <489C1686.8000607@netconfcentral.com> X-OriginalArrivalTime: 08 Aug 2008 10:12:23.0136 (UTC) FILETIME=[3FF55E00:01C8F93F] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org, netconf mailing list Subject: Re: [Netconf] [netmod] leaf encoding rules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: >> Maybe we should get with-defaults standardized. >> >> I hereby ask the NETCONF/NETMOD community and specially the chairs of >> NETCONF if they would accept as a new NETCONF work item a small draft >> adding a with-defaults option to Netconf as a capability. As my >> Partial locking draft seems to wind down (Is this wishful thinking :-) >> I might even volunteer to write a draft on with-defaults. >> > > You mean something like this: > > http://tools.ietf.org/html/draft-bierman-ncx-ext-00 > > I would be interested in pulling out just the with-defaults > and republishing this draft. IMO, a capability is overkill, > but if an agent wants to suppress defaults unless explicitly > requested to send them, that should be OK, as long > as there is a status flag the manager can retrieve that > indicates this is how the agent works. > I think that would be splendid. The flag you mention could go into the Netconf Monitoring model Scott is working on (timing, extensibility of that model). On the other hand some might argue, that if we already have one method to indicate optional behavior (capabilities) why invent a second one (flags). If you do this yourself good. if you think I should help or do it myself say so. Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 8 03:13:25 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBAAA3A687F; Fri, 8 Aug 2008 03:13:24 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C143A6967; Fri, 8 Aug 2008 03:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56FkErNHIZrF; Fri, 8 Aug 2008 03:13:22 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9AC5E3A6D25; Fri, 8 Aug 2008 03:12:24 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B817620030; Fri, 8 Aug 2008 12:12:23 +0200 (CEST) X-AuditID: c1b4fb3c-ad8cdbb0000015b5-12-489c1c077c25 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 97AC120535; Fri, 8 Aug 2008 12:12:23 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 12:12:23 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 12:12:23 +0200 Message-ID: <489C1BFF.70707@ericsson.com> Date: Fri, 08 Aug 2008 12:12:15 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <489B310A.5070802@andybierman.com> <20080807.220904.108338659.mbj@tail-f.com> <489C0F56.6030801@ericsson.com> <489C1686.8000607@netconfcentral.com> In-Reply-To: <489C1686.8000607@netconfcentral.com> X-OriginalArrivalTime: 08 Aug 2008 10:12:23.0136 (UTC) FILETIME=[3FF55E00:01C8F93F] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org, netconf mailing list Subject: Re: [Netconf] [netmod] leaf encoding rules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: >> Maybe we should get with-defaults standardized. >> >> I hereby ask the NETCONF/NETMOD community and specially the chairs of >> NETCONF if they would accept as a new NETCONF work item a small draft >> adding a with-defaults option to Netconf as a capability. As my >> Partial locking draft seems to wind down (Is this wishful thinking :-) >> I might even volunteer to write a draft on with-defaults. >> > > You mean something like this: > > http://tools.ietf.org/html/draft-bierman-ncx-ext-00 > > I would be interested in pulling out just the with-defaults > and republishing this draft. IMO, a capability is overkill, > but if an agent wants to suppress defaults unless explicitly > requested to send them, that should be OK, as long > as there is a status flag the manager can retrieve that > indicates this is how the agent works. > I think that would be splendid. The flag you mention could go into the Netconf Monitoring model Scott is working on (timing, extensibility of that model). On the other hand some might argue, that if we already have one method to indicate optional behavior (capabilities) why invent a second one (flags). If you do this yourself good. if you think I should help or do it myself say so. Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 8 04:27:04 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3646F3A6C95; Fri, 8 Aug 2008 04:27:04 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C6F23A6850 for ; Fri, 8 Aug 2008 04:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMkNLQ2JqLR5 for ; Fri, 8 Aug 2008 04:27:02 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 915E53A6C92 for ; Fri, 8 Aug 2008 04:26:54 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B28592068D for ; Fri, 8 Aug 2008 13:26:50 +0200 (CEST) X-AuditID: c1b4fb3c-ab0c8bb0000015b5-b5-489c2d7a99a4 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A27C2203E0 for ; Fri, 8 Aug 2008 13:26:50 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 13:26:50 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 13:26:50 +0200 Message-ID: <489C2D73.3090405@ericsson.com> Date: Fri, 08 Aug 2008 13:26:43 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf mailing list X-OriginalArrivalTime: 08 Aug 2008 11:26:50.0313 (UTC) FILETIME=[A69A7B90:01C8F949] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] [Fwd: New Version Notification for draft-ietf-netconf-partial-lock-03] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, I updated the partial-lock draft. I think it is ready for WG last call. Balazs -------- Original Message -------- Subject: New Version Notification for draft-ietf-netconf-partial-lock-03 Date: Fri, 8 Aug 2008 04:25:36 -0700 (PDT) From: IETF I-D Submission Tool To: balazs.lengyel@ericsson.com CC: mbj@tail-f.com A new version of I-D, draft-ietf-netconf-partial-lock-03.txt has been successfuly submitted by Balazs Lengyel and posted to the IETF repository. Filename: draft-ietf-netconf-partial-lock Revision: 03 Title: Partial Lock RPC for NETCONF Creation_date: 2008-08-06 WG ID: netconf Number_of_pages: 19 Abstract: The NETCONF protocol defines the lock and unlock RPCs that lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a cFrom netconf-bounces@ietf.org Fri Aug 8 04:27:04 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3646F3A6C95; Fri, 8 Aug 2008 04:27:04 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C6F23A6850 for ; Fri, 8 Aug 2008 04:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMkNLQ2JqLR5 for ; Fri, 8 Aug 2008 04:27:02 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 915E53A6C92 for ; Fri, 8 Aug 2008 04:26:54 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B28592068D for ; Fri, 8 Aug 2008 13:26:50 +0200 (CEST) X-AuditID: c1b4fb3c-ab0c8bb0000015b5-b5-489c2d7a99a4 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A27C2203E0 for ; Fri, 8 Aug 2008 13:26:50 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 13:26:50 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 13:26:50 +0200 Message-ID: <489C2D73.3090405@ericsson.com> Date: Fri, 08 Aug 2008 13:26:43 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf mailing list X-OriginalArrivalTime: 08 Aug 2008 11:26:50.0313 (UTC) FILETIME=[A69A7B90:01C8F949] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] [Fwd: New Version Notification for draft-ietf-netconf-partial-lock-03] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, I updated the partial-lock draft. I think it is ready for WG last call. Balazs -------- Original Message -------- Subject: New Version Notification for draft-ietf-netconf-partial-lock-03 Date: Fri, 8 Aug 2008 04:25:36 -0700 (PDT) From: IETF I-D Submission Tool To: balazs.lengyel@ericsson.com CC: mbj@tail-f.com A new version of I-D, draft-ietf-netconf-partial-lock-03.txt has been successfuly submitted by Balazs Lengyel and posted to the IETF repository. Filename: draft-ietf-netconf-partial-lock Revision: 03 Title: Partial Lock RPC for NETCONF Creation_date: 2008-08-06 WG ID: netconf Number_of_pages: 19 Abstract: The NETCONF protocol defines the lock and unlock RPCs that lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuonfiguration datastore. The IETF Secretariat. -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ration datastore. The IETF Secretariat. -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 8 04:30:02 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C67353A6CC0; Fri, 8 Aug 2008 04:30:02 -0700 (PDT) X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0CF4B3A6CC0; Fri, 8 Aug 2008 04:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808113002.0CF4B3A6CC0@core3.amsl.com> Date: Fri, 8 Aug 2008 04:30:02 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-partial-lock-03.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: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Partial Lock RPC for NETCONF Author(s) : B. Lengyel, M. Bjorklund Filename : draft-ietf-netconf-partial-lock-03.txt Pages : 19 Date : 2008-08-08 The NETCONF protocol defines the lock and unlock RPCs that lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-partial-lock-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-partial-lock-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-08042536.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --NextPart-- From netconf-bounces@ietf.org Fri Aug 8 04:30:02 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C67353A6CC0; Fri, 8 Aug 2008 04:30:02 -0700 (PDT) X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0CF4B3A6CC0; Fri, 8 Aug 2008 04:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808113002.0CF4B3A6CC0@core3.amsl.com> Date: Fri, 8 Aug 2008 04:30:02 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-partial-lock-03.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: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Partial Lock RPC for NETCONF Author(s) : B. Lengyel, M. Bjorklund Filename : draft-ietf-netconf-partial-lock-03.txt Pages : 19 Date : 2008-08-08 The NETCONF protocol defines the lock and unlock RPCs that lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-partial-lock-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-partial-lock-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-08042536.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --NextPart-- From netconf-bounces@ietf.org Fri Aug 8 09:17:04 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65C123A6C89; Fri, 8 Aug 2008 09:17:04 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9F283A69F4 for ; Fri, 8 Aug 2008 09:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.313, 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 6BPkt-L2WuZZ for ; Fri, 8 Aug 2008 09:17:03 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 100013A6827 for ; Fri, 8 Aug 2008 09:17:03 -0700 (PDT) Received: (qmail 71503 invoked from network); 8 Aug 2008 16:17:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 8 Aug 2008 16:17:02 -0000 X-YMail-OSG: olfLywsVM1lAX5K7yzot0ue.WFDBJ1kHdQ7mu4d4R2QSeLgjVQ1gB_u0oapzmnn5.JIklLWVIns5SaQurmpnqHQyboKFjfk6hL.GO1wO4Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489C717C.70906@netconfcentral.com> Date: Fri, 08 Aug 2008 09:17:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Leif Johansson References: <489B6539.20307@netconfcentral.com> <20080807.231856.142574379.mbj@tail-f.com> <200808081027.58888.leifj@it.su.se> In-Reply-To: <200808081027.58888.leifj@it.su.se> Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] XML element order X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Leif Johansson wrote: > On Thursday 07 August 2008 23:18:56 Martin Bjorklund wrote: >> Andy Bierman wrote: >>> Hi, > > Sorry for cross-posting this but this is probably critically important > for netmod wg too... > >>> Is the NETCONF agent allowed to accept XML elements >>> out of the specified order? >> Do you mean inside the protocol or inside the data? >> > > I think this question may be related to the question I asked at the > mic in Dublin about the uniqueness of representation of a yang > model in xml form. A necessary (but probably not sufficient) > requirement that since yang lists are order-preserving the > corresponging xml representation needs to be order-preserving > too. > > It is absolutely critical for yang that there is a *unique* mapping > between yang and xml since yang uses xpath. > I am talking about XML elements within NETCONF PDUs on the wire. There are a few corner-cases in the YANG mapping (leaf-list, ordered-by user, keys) in which relative order among a sibling node set is significant. I don't see what XPath has to do with it. As long as the agent maintains the same conceptual XML instance document for a database, XPath will always work the same on that agent. XPath in NETCONF only applies to this database, not the PDUs. > Cheers Leif Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 8 09:17:04 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65C123A6C89; Fri, 8 Aug 2008 09:17:04 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9F283A69F4 for ; Fri, 8 Aug 2008 09:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.313, 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 6BPkt-L2WuZZ for ; Fri, 8 Aug 2008 09:17:03 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 100013A6827 for ; Fri, 8 Aug 2008 09:17:03 -0700 (PDT) Received: (qmail 71503 invoked from network); 8 Aug 2008 16:17:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 8 Aug 2008 16:17:02 -0000 X-YMail-OSG: olfLywsVM1lAX5K7yzot0ue.WFDBJ1kHdQ7mu4d4R2QSeLgjVQ1gB_u0oapzmnn5.JIklLWVIns5SaQurmpnqHQyboKFjfk6hL.GO1wO4Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489C717C.70906@netconfcentral.com> Date: Fri, 08 Aug 2008 09:17:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Leif Johansson References: <489B6539.20307@netconfcentral.com> <20080807.231856.142574379.mbj@tail-f.com> <200808081027.58888.leifj@it.su.se> In-Reply-To: <200808081027.58888.leifj@it.su.se> Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] XML element order X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Leif Johansson wrote: > On Thursday 07 August 2008 23:18:56 Martin Bjorklund wrote: >> Andy Bierman wrote: >>> Hi, > > Sorry for cross-posting this but this is probably critically important > for netmod wg too... > >>> Is the NETCONF agent allowed to accept XML elements >>> out of the specified order? >> Do you mean inside the protocol or inside the data? >> > > I think this question may be related to the question I asked at the > mic in Dublin about the uniqueness of representation of a yang > model in xml form. A necessary (but probably not sufficient) > requirement that since yang lists are order-preserving the > corresponging xml representation needs to be order-preserving > too. > > It is absolutely critical for yang that there is a *unique* mapping > between yang and xml since yang uses xpath. > I am talking about XML elements within NETCONF PDUs on the wire. There are a few corner-cases in the YANG mapping (leaf-list, ordered-by user, keys) in which relative order among a sibling node set is significant. I don't see what XPath has to do with it. As long as the agent maintains the same conceptual XML instance document for a database, XPath will always work the same on that agent. XPath in NETCONF only applies to this database, not the PDUs. > Cheers Leif Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 8 11:18:48 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6704A3A6D93; Fri, 8 Aug 2008 11:18:48 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088FE28C114; Fri, 8 Aug 2008 11:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIORJsm7sj2y; Fri, 8 Aug 2008 11:18:47 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3DD803A68E7; Fri, 8 Aug 2008 11:18:47 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Fri, 08 Aug 2008 11:17:40 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 11:18:46 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 11:18:45 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 11:18: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 m78IIiu80065; Fri, 8 Aug 2008 11:18:44 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m78IFSAR081219; Fri, 8 Aug 2008 18:15:29 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808081815.m78IFSAR081219@idle.juniper.net> To: Andy Bierman In-reply-to: <489C1686.8000607@netconfcentral.com> Date: Fri, 08 Aug 2008 14:15:28 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Aug 2008 18:18:45.0450 (UTC) FILETIME=[31F91AA0:01C8F983] Cc: netconf mailing list , netmod@ietf.org Subject: Re: [Netconf] [netmod] leaf encoding rules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >http://tools.ietf.org/html/draft-bierman-ncx-ext-00 Two comments: (a) with-defaults shouldn't be an attribute on . It should be an element on the appropriate RPCs (get-config). (b) Having a mechanism to learn default values is fine, but since defaults will increase the size of configurations by several orders of magnitude, making this the base behavior is a Very Bad Idea. It should be an option. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 8 11:18:48 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6704A3A6D93; Fri, 8 Aug 2008 11:18:48 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088FE28C114; Fri, 8 Aug 2008 11:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIORJsm7sj2y; Fri, 8 Aug 2008 11:18:47 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3DD803A68E7; Fri, 8 Aug 2008 11:18:47 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Fri, 08 Aug 2008 11:17:40 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 11:18:46 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 11:18:45 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 11:18: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 m78IIiu80065; Fri, 8 Aug 2008 11:18:44 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m78IFSAR081219; Fri, 8 Aug 2008 18:15:29 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808081815.m78IFSAR081219@idle.juniper.net> To: Andy Bierman In-reply-to: <489C1686.8000607@netconfcentral.com> Date: Fri, 08 Aug 2008 14:15:28 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Aug 2008 18:18:45.0450 (UTC) FILETIME=[31F91AA0:01C8F983] Cc: netconf mailing list , netmod@ietf.org Subject: Re: [Netconf] [netmod] leaf encoding rules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >http://tools.ietf.org/html/draft-bierman-ncx-ext-00 Two comments: (a) with-defaults shouldn't be an attribute on . It should be an element on the appropriate RPCs (get-config). (b) Having a mechanism to learn default values is fine, but since defaults will increase the size of configurations by several orders of magnitude, making this the base behavior is a Very Bad Idea. It should be an option. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 8 11:26:50 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC203A6BC0; Fri, 8 Aug 2008 11:26:50 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1503A68EB; Fri, 8 Aug 2008 11:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3D0ZlT-Gt9o; Fri, 8 Aug 2008 11:26:47 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id C2AC03A6892; Fri, 8 Aug 2008 11:26:45 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Fri, 08 Aug 2008 11:26:33 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 11:26:44 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 11:26:44 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 11:26: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 m78IQhu82655; Fri, 8 Aug 2008 11:26:43 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m78INR6r081269; Fri, 8 Aug 2008 18:23:28 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808081823.m78INR6r081269@idle.juniper.net> To: Leif Johansson In-reply-to: <200808081027.58888.leifj@it.su.se> Date: Fri, 08 Aug 2008 14:23:27 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Aug 2008 18:26:44.0141 (UTC) FILETIME=[4F4B8DD0:01C8F984] Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] XML element order X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Leif Johansson writes: >I think this question may be related to the question I asked at the >mic in Dublin about the uniqueness of representation of a yang >model in xml form. A necessary (but probably not sufficient) >requirement that since yang lists are order-preserving the >corresponging xml representation needs to be order-preserving >too. > >It is absolutely critical for yang that there is a *unique* mapping >between yang and xml since yang uses xpath. XML encoding should be predictable and consistent, but need for "uniqueness" implies a level of exactness that XML is meant to be the solution for. If you define two leafs in a container, your program (and certainly any XPath expressions you write) should not can which order those elements arrive in, _unless_ that order carries some semantic information. rpc ping { input { leaf size { ... } leaf count { ... } leaf wait { ... } } } There is no semantic difference between: 1024 10 5 and: 10 1024 5 or: 1010245 Order and whitespace differences only matter when they matter, and shouldn't become CLRs any other time. The XPath expression "ping/count" finds the count no matter the order. Assuming that "ping/*[position() = 1]" is the count will give you fragile code. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 8 11:26:50 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC203A6BC0; Fri, 8 Aug 2008 11:26:50 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1503A68EB; Fri, 8 Aug 2008 11:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3D0ZlT-Gt9o; Fri, 8 Aug 2008 11:26:47 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id C2AC03A6892; Fri, 8 Aug 2008 11:26:45 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Fri, 08 Aug 2008 11:26:33 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 11:26:44 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 11:26:44 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 11:26: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 m78IQhu82655; Fri, 8 Aug 2008 11:26:43 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m78INR6r081269; Fri, 8 Aug 2008 18:23:28 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808081823.m78INR6r081269@idle.juniper.net> To: Leif Johansson In-reply-to: <200808081027.58888.leifj@it.su.se> Date: Fri, 08 Aug 2008 14:23:27 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Aug 2008 18:26:44.0141 (UTC) FILETIME=[4F4B8DD0:01C8F984] Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] XML element order X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Leif Johansson writes: >I think this question may be related to the question I asked at the >mic in Dublin about the uniqueness of representation of a yang >model in xml form. A necessary (but probably not sufficient) >requirement that since yang lists are order-preserving the >corresponging xml representation needs to be order-preserving >too. > >It is absolutely critical for yang that there is a *unique* mapping >between yang and xml since yang uses xpath. XML encoding should be predictable and consistent, but need for "uniqueness" implies a level of exactness that XML is meant to be the solution for. If you define two leafs in a container, your program (and certainly any XPath expressions you write) should not can which order those elements arrive in, _unless_ that order carries some semantic information. rpc ping { input { leaf size { ... } leaf count { ... } leaf wait { ... } } } There is no semantic difference between: 1024 10 5 and: 10 1024 5 or: 1010245 Order and whitespace differences only matter when they matter, and shouldn't become CLRs any other time. The XPath expression "ping/count" finds the count no matter the order. Assuming that "ping/*[position() = 1]" is the count will give you fragile code. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 8 15:13:30 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE773A6B45; Fri, 8 Aug 2008 15:13:30 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32F0A3A6A2D for ; Fri, 8 Aug 2008 15:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=0.228, 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 3oJdFg5rjHut for ; Fri, 8 Aug 2008 15:13:29 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 113443A69C4 for ; Fri, 8 Aug 2008 15:13:29 -0700 (PDT) Received: (qmail 25760 invoked from network); 8 Aug 2008 22:06:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 8 Aug 2008 22:06:48 -0000 X-YMail-OSG: ehm04jgVM1kAXG5Tnp_0IxhUeNKSxWyjXx77e5dWCLtyZ1gIG_MfvbzcHbQ2FGpJhSHrrGaD16qFoa3M46DrvK7ZbrfbZKMAeH_xRWg5GC0Ivc0X80CQmOrAeqimIdI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489CC376.9060509@netconfcentral.com> Date: Fri, 08 Aug 2008 15:06:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808081815.m78IFSAR081219@idle.juniper.net> In-Reply-To: <200808081815.m78IFSAR081219@idle.juniper.net> Cc: netconf mailing list , netmod@ietf.org Subject: Re: [Netconf] [netmod] leaf encoding rules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> http://tools.ietf.org/html/draft-bierman-ncx-ext-00 > > Two comments: > (a) with-defaults shouldn't be an attribute on . It should be > an element on the appropriate RPCs (get-config). IMO, it is easier and more consistent to use the XML attribute mechanism already defined for the element. The same mechanism works for all standard and vendor RPC methods. > (b) Having a mechanism to learn default values is fine, but since > defaults will increase the size of configurations by several orders > of magnitude, making this the base behavior is a Very Bad Idea. It > should be an option. agreed. A read-only leaf in the netconf-state spec is fine. But if you support the (separate) 'with-defaults' capability, then you must return these default leafs when 'with-defaults' is set to true. It is OK to make this a marketing decision, similar to retrieving all the YANG, XSD, or RNG files directly from the agent. IMO, NE devices will continue to get smarter, and 1 way to do that is to help the operator quickly get out of a jam with instant, context-sensitive documentation. > > Thanks, > Phil > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinFrom netconf-bounces@ietf.org Fri Aug 8 15:13:30 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE773A6B45; Fri, 8 Aug 2008 15:13:30 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32F0A3A6A2D for ; Fri, 8 Aug 2008 15:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=0.228, 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 3oJdFg5rjHut for ; Fri, 8 Aug 2008 15:13:29 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 113443A69C4 for ; Fri, 8 Aug 2008 15:13:29 -0700 (PDT) Received: (qmail 25760 invoked from network); 8 Aug 2008 22:06:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.240 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 8 Aug 2008 22:06:48 -0000 X-YMail-OSG: ehm04jgVM1kAXG5Tnp_0IxhUeNKSxWyjXx77e5dWCLtyZ1gIG_MfvbzcHbQ2FGpJhSHrrGaD16qFoa3M46DrvK7ZbrfbZKMAeH_xRWg5GC0Ivc0X80CQmOrAeqimIdI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <489CC376.9060509@netconfcentral.com> Date: Fri, 08 Aug 2008 15:06:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808081815.m78IFSAR081219@idle.juniper.net> In-Reply-To: <200808081815.m78IFSAR081219@idle.juniper.net> Cc: netconf mailing list , netmod@ietf.org Subject: Re: [Netconf] [netmod] leaf encoding rules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> http://tools.ietf.org/html/draft-bierman-ncx-ext-00 > > Two comments: > (a) with-defaults shouldn't be an attribute on . It should be > an element on the appropriate RPCs (get-config). IMO, it is easier and more consistent to use the XML attribute mechanism already defined for the element. The same mechanism works for all standard and vendor RPC methods. > (b) Having a mechanism to learn default values is fine, but since > defaults will increase the size of configurations by several orders > of magnitude, making this the base behavior is a Very Bad Idea. It > should be an option. agreed. A read-only leaf in the netconf-state spec is fine. But if you support the (separate) 'with-defaults' capability, then you must return these default leafs when 'with-defaults' is set to true. It is OK to make this a marketing decision, similar to retrieving all the YANG, XSD, or RNG files directly from the agent. IMO, NE devices will continue to get smarter, and 1 way to do that is to help the operator quickly get out of a jam with instant, context-sensitive documentation. > > Thanks, > Phil > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/fo/netconf listinfo/netconf From netconf-bounces@ietf.org Sat Aug 9 14:15:53 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C69853A689E; Sat, 9 Aug 2008 14:15:53 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1513A6835; Sat, 9 Aug 2008 14:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzhFFYRN1806; Sat, 9 Aug 2008 14:15:51 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id AF8B13A6816; Sat, 9 Aug 2008 14:15:51 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Sat, 09 Aug 2008 14:15:49 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 9 Aug 2008 14:15:03 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 9 Aug 2008 14:15:03 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Aug 2008 14:15: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 m79LF1u57869; Sat, 9 Aug 2008 14:15:01 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m79LBigd088169; Sat, 9 Aug 2008 21:11:44 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808092111.m79LBigd088169@idle.juniper.net> To: Andy Bierman In-reply-to: <489CC376.9060509@netconfcentral.com> Date: Sat, 09 Aug 2008 17:11:44 -0400 From: Phil Shafer X-OriginalArrivalTime: 09 Aug 2008 21:15:02.0833 (UTC) FILETIME=[FCFF6A10:01C8FA64] Cc: netconf mailing list , netmod@ietf.org Subject: Re: [Netconf] [netmod] leaf encoding rules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >IMO, it is easier and more consistent to use the XML attribute >mechanism already defined for the element. The same mechanism works >for all standard and vendor RPC methods. "works" != "makes sense". with-defaults makes no sense for many RPCs. It should only be defined for those RPCs where it makes sense. Imagine if we allow this as a general concept and everyone starts stuffing all their cruft in because is "easier". Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Aug 9 14:15:53 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C69853A689E; Sat, 9 Aug 2008 14:15:53 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1513A6835; Sat, 9 Aug 2008 14:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzhFFYRN1806; Sat, 9 Aug 2008 14:15:51 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id AF8B13A6816; Sat, 9 Aug 2008 14:15:51 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Sat, 09 Aug 2008 14:15:49 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 9 Aug 2008 14:15:03 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 9 Aug 2008 14:15:03 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Aug 2008 14:15: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 m79LF1u57869; Sat, 9 Aug 2008 14:15:01 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m79LBigd088169; Sat, 9 Aug 2008 21:11:44 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808092111.m79LBigd088169@idle.juniper.net> To: Andy Bierman In-reply-to: <489CC376.9060509@netconfcentral.com> Date: Sat, 09 Aug 2008 17:11:44 -0400 From: Phil Shafer X-OriginalArrivalTime: 09 Aug 2008 21:15:02.0833 (UTC) FILETIME=[FCFF6A10:01C8FA64] Cc: netconf mailing list , netmod@ietf.org Subject: Re: [Netconf] [netmod] leaf encoding rules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >IMO, it is easier and more consistent to use the XML attribute >mechanism already defined for the element. The same mechanism works >for all standard and vendor RPC methods. "works" != "makes sense". with-defaults makes no sense for many RPCs. It should only be defined for those RPCs where it makes sense. Imagine if we allow this as a general concept and everyone starts stuffing all their cruft in because is "easier". Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Aug 10 03:49:26 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5B53A6B24; Sun, 10 Aug 2008 03:49:26 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E0C3A6B02 for ; Sun, 10 Aug 2008 03:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vi3PPWtBNiwi for ; Sun, 10 Aug 2008 03:49:23 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 3EB003A6B24 for ; Sun, 10 Aug 2008 03:49:21 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m7AAelUS008901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 10 Aug 2008 12:40:47 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m7AAel1F025509 for ; Sun, 10 Aug 2008 12:40:47 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 10 Aug 2008 12:40:47 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8FAD5.8AABD85E" Date: Sun, 10 Aug 2008 12:40:44 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Minutes of the Netconf Session at IETF 72 Thread-Index: Acj61YlPJDPDcXRhQlSOkIuGFqCwxQ== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 10 Aug 2008 10:40:47.0640 (UTC) FILETIME=[8CBF8980:01C8FAD5] Subject: [Netconf] Draft Minutes of the Netconf Session at IETF 72 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8FAD5.8AABD85E Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C8FAD5.8AABD85E" ------_=_NextPart_002_01C8FAD5.8AABD85E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All,=20 attached are the draft minutes for the Netconf Session=20 at IETF 72 we have prepared from the notes of the minute=20 takers (many thanks again to Juergen and David H. for=20 taking notes!! :)=20 <>=20 Please send us your change requests or corrections by=20 25th of August. We'll put it to the meeting materials site=20 as the preliminary version.=20 Thank you.=20 Bert & Mehmet=20 ------_=_NextPart_002_01C8FAD5.8AABD85E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Draft Minutes of the Netconf Session at IETF 72

Hi All,
attached are the = draft minutes for the Netconf Session
at IETF 72 we have prepared from the notes of the minute
takers (many thanks again to Juergen and David H. for
taking notes!! :)
= <<Draft_IETF72-Netconf-Minutes.txt>>
Please send us = your change requests or corrections by
25th of August. We'll put it to the meeting materials site
as the preliminary version. =
Thank = you.
Bert & Mehmet =

------_=_NextPart_002_01C8FAD5.8AABD85E-- ------_=_NextPart_001_01C8FAD5.8AABD85E Content-Type: text/plain; name="Draft_IETF72-Netconf-Minutes.txt" Content-Transfer-Encoding: base64 Content-Description: Draft_IETF72-Netconf-Minutes.txt Content-Disposition: attachment; filename="Draft_IETF72-Netconf-Minutes.txt" DQotLS0gUHJlbGltaW5hcnkgIC0gQXVndXN0IDEwLCAyMDA4IC0tLQ0KDQpNaW51dGVzIG9mIHRo ZSBOZXR3b3JrIENvbmZpZ3VyYXRpb24gV0cgU2Vzc2lvbiBhdCB0aGUgSUVURiAjNzIsIER1Ymxp biwgSXJlbGFuZCANClRVRVNEQVksIEp1bHkgMjksIDIwMDggMTg1MC0xOTUwIA0KDQpXRyBDaGFp cnM6IA0KQmVydCBXaWpuZW4gPGJlcnRpZXRmQGJ3aWpuZW4ubmV0PiANCk1laG1ldCBFcnN1ZSA8 bWVobWV0LmVyc3VlQG5zbi5jb20+IA0KQUQ6IERhbiBSb21hc2NhbnUNClNlY3VyaXR5IEFEOiBU aW0gUG9saw0KDQpUaGFuayB5b3UgdG8gdGhlIG1pbnV0ZSB0YWtlcnM6DQpKdWVyZ2VuIFNjaG9l bndhZWxkZXIsIERhdmlkIEhhcnJpbmd0b24NCg0KQWdlbmRhIGFuZCBXRyBzdGF0dXMgc2xpZGVz OiBodHRwOi8vd3d3My5pZXRmLm9yZy9wcm9jZWVkaW5ncy8wOGp1bC9zbGlkZXMvbmV0Y29uZi0w LnBwdA0KDQpUaGVyZSB3ZXJlIDM1IHBlcnNvbnMgaW4gdGhlIE5FVENPTkYgc2Vzc2lvbi4NCg0K QmVydCBXaWpuZW4gdGFrZXMgY2FyZSBvZiB0aGUgYWRtaW5pc3RyaXZpYS4NCg0KV0cgc3RhdHVz IHJldmlldyBnaXZlbiBieSBNZWhtZXQgRXJzdWUuDQpORVRDT05GIE5vdGlmaWNhdGlvbiBkcmFm dCBoYXMgYmVlbiBwdWJsaXNoZWQgYXMgUkZDIDUyNzcuDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpORVRDT05GIE1v bml0b3JpbmcgU2NoZW1hIChNYXJrIFNjb3R0ICkNCg0KU2xpZGVzOiBodHRwOi8vd3d3My5pZXRm Lm9yZy9wcm9jZWVkaW5ncy8wOGp1bC9zbGlkZXMvbmV0Y29uZi0xLnBwdA0KIA0KTWFyayBTY290 dCBwcmVzZW50cyB0aGUgbW9uaXRvcmluZyBzbGlkZXMNCklzc3VlICMxOiBXaGljaCB0ZXJtaW5v bG9neSBzaG91bGQgYmUgdXNlZD8gc2NoZW1hIG9yIG1vZGVsIG9yIGRhdGEgbW9kZWwgLi4uPw0K RGF2ZSBIYXJyaW5ndG9uOiB3ZSB1c2VkIHRvIG1ha2UgYSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGRh dGEgbW9kZWxzIGFuZCBpbmZvcm1hdGlvbiBtb2RlbHMNCkRhdmlkIFBhcnRhaW46IGluIFlBTkcs IHdlIGNhbGwgdGhpbmdzIGRhdGEgbW9kZWxzIG9yIG1vZHVsZXMNClNoYXJvbiBDaGlzaG9sbTog aW4gWE1MIHdvcmxkLCBwZW9wbGUgdXNlIHRoZSB0ZXJtIHNjaGVtYQ0KUGhpbCBTaGFmZXI6IHNp bmNlIHRoaXMgaXMgbm90IFhTRCBvbmx5LCB3aHkgbm90IHVzZSBkYXRhIG1vZGVsDQpEYXZlOiBS RkMgMzQ0NCBzaG91bGQgYmUgY2hlY2tlZCB3aGV0aGVyIGl0IGFwcGxpZXMNCkRhdmlkIFA6IHBy ZWZlciBkYXRhIG1vZGVsDQpNYXJ0aW4gQmpvcmtsdW5kOiBXaGF0IGFib3V0IHRoZSBnZXQtc2No ZW1hIFJQQz8NCkJlcnQ6IFRoYXRzIGNvbnNpc3RlbnQgd2l0aCB0aGUgTkVUQ09ORiBkb2N1bWVu dHMgYW5kIHdlIHNob3VsZCBjb25pdG51ZSB3aXRoIHRoYXQgcmlnaHQ/DQpCZXJ0OiBJIHRoaW5r IHRoaXMgaGFzIG5vdCBiZWVuIGRpc2N1c3NlZCBvbiB0aGUgbWFpbGxpc3QgeWV0LiBXZSdsbCB0 cnkgdG8gcmVhY2ggY29uc2Vuc3VzIG9uIHRoZSBtYWlsbGlzdCBvbiB0aGF0Lg0KPT4gcHV0IHVw IG9uIHRoZSBtYWlsaW5nIGxpc3QgdG8gc2VlIHdoZXJlIHRoZXJlIGlzIGNvbnNlbnN1cw0KSXNz dWUgIzI6IGxhY2sgb2YgYWdyZWVkIFhTRCBkZWZpbml0aW9ucyBmb3IgZGF0YSB0eXBlcyB0byB1 c2UuDQpNYXJrOiBIb3cgZG9lcyB0aGlzIGRpc2N1c3Npb24gaW1wYWN0IGN1cnJlbnQgd29yayB0 byBzdGFuZGFyZGl6ZSBjb250ZW50Pw0KRGF2ZTogT1BTQVdHIHdvcmtzIG9uIFNNSXYyIHRyYW5z bGF0aW9ucyB0byBYU0QuIElmIHlvdSB3YW50IHRvIGRpc2N1c3MgdGhpcyB3b3JrLCB0aGlzIGNh biBiZSBkb25lIGluIHRoYXQgd29ya2dyb3VwLg0KTWFyazogRm9yIHRob3NlIHRoYXQgYXJlIGFs cmVhZHkgYmVpbmcgY292ZXJlZCBpbiBCb2IncyB3b3JrIHdlIGNhbiB1c2UgdGhvc2UgYXMgaXMg YnV0IGluIGNhc2Ugd2Ugd2FudCBhIGRpZmZlcmVudCBkYXRhIHR5cGUgb3IgYW4gZW5oYW5jZWQg ZGF0YSB0eXBlIHRoYXQncyBub3QgY292ZXJlZCBieSBCb2IncyB3b3JrLiBUaGVyZSBhcmUgc3Rp bGwgY29tcGxleCBkYXRhIHR5cGVzIHdoaWNoIHdlIG5lZWQuIEFyZSB3ZSBkZWZpbmluZyB0aGVt IG5vdyBhbmQgdXNlPw0KRGF2aWQgUDogQm9iIE5hdGFsZSwgSvxyZ2VuIFNjaPZud+RsZGVyLCBN YXJrIHNob3VsZCBzaXQgZG93biBhbmQgZmlndXJlIG91dCBhIGdvb2Qgd2F5IGZvcndhcmQgYW5k IHByb3Bvc2UgaXQgdG8gdGhlIGxpc3QsIGNyb3NzLXBvc3QgdG8gT1BTIGFyZWEgd29ya2dyb3Vw Lg0KTWFyazogSXMgdGhhdCBiZWNhdXNlIHdlIGhhdmUgYWdyZWVkIHRoYXQgd2UgbXVzdCBoYXZl IGludHJpbnNpY2x5IHRoZSBzYW1lIGRhdGEgdHlwZXMgYXMgZGVmaW5lZCBpbiBCb2IncyB3b3Jr Pw0KQmVydDogV2UgZGlkIG5vdCBhZ3JlZSBidXQgd2Uga25vdyB0aGVyZSBpcyBzaW1pbGFyIHdv cmssIHNwZWFrIHdpdGggdGhvc2UgcGVvcGxlIGFuZCB0cnkgdG8gY29tZSB1cCB3aXRoIG9uZSBz b2x1dGlvbi4NCkRhdmU6IE9QU0FXRyBpcyBkaWZmZXJlbnQgZnJvbSB3aGF0IHlvdSBhcmUgZG9p bmcgaGVyZSwgaXQgaXMgb25seSBkZWFsaW5nIHdpdGggU01JdjItPiBYU0QgdHJhbnNsYXRpb24u IFRoaXMgaXMgbm90IHRoZSBzYW1lIHdvcmsgaXQgaGFzIGEgZGlmZmVyZW50IGZva3VzDQpNYXJr OiBBcmd1YWJseSBtb3JlIGRhdGEgdHlwZXMgbWlnaHQgY29tZSB1cCBhcyB3ZSBkZWZpbmUgbW9y ZSBjb250ZW50LiBXaGVuIHNvbWVvbmUgZGVmaW5lcyBORVRDT05GIGNvbnRlbnQgYXJlIHdlIGF0 IGxlYXN0IHdpdGhpbiB0aGUgTkVUQ09ORiBjb250ZXh0IGdvaW5nIHRvIHVzZSBpdC4NCkr8cmdl bjogV2l0aCBZQU5HL05FVENPTkYsIHdlIGhhdmUgYSBjaGlja2VuIGFuZCBlZ2cgcHJvYmxlbS4g V2UgY2FuIG9ubHkgc29sdmUgdGhpcyBieSBtYWtpbmcgYSBiZXN0IGd1ZXNzIGFuZCBnbyBhaGVh ZDsgbW9yZSBnZW5lcmFsIHF1ZXN0aW9uIGlzIHdoYXQgaGFwcGVucyBpZiB5b3UgZG8gZGlmZmVy ZW50IFNNSXYyIHRyYW5zbGF0aW9ucy4gU01JdjItPi4uLi0+WFNEIGlzc3VlIGlzIG5vdCBhIHBy b2JsZW0gdG8gYmUgc29sdmVkIGluIHRoaXMgV0cNCkJlcnQ6IEJlZm9yZSBXR0xDIHdlIHNob3Vs ZCB0aGluayBvbiB0aGVzZSBpc3N1ZXMuDQo9PiBUaGUgaXNzdWUgd2lsbCBiZSBicm91Z2h0IHRv IHRoZSBtYWlsaW5nIGxpc3QuDQoNCg0KUGFydGlhbCBMb2NrIFJQQyBmb3IgTkVUQ09ORiAoQmFs YXpzIExlbmd5ZWwpDQoNClNsaWRlczogaHR0cDovL3d3dzMuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv MDhqdWwvc2xpZGVzL25ldGNvbmYtMy5wcHQNCg0KQmFsYXpzIExlbmd5ZWwgcHJlc2VudHMgdGhl IGxvY2tpbmcgZHJhZnQNCklzc3VlICMxOiByZW1vdmUgZW1wdHkgbG9ja3M/DQpCYWxhenM6IHBy b3Bvc2FsIHRvIGtlZXAgZW1wdHkgbG9ja3MgZm9yIGNvbnNpc3RlbmN5IHJlYXNvbnMuIA0KSXNz dWUgIzI6IE5lZWQgdG8gYWRkIHNvbWUgY2xhcmlmaWNhdGlvbnMgdGhhdDogRG9lcyB0aGUgZ3Jh bnVsYXIgbG9ja2luZyBwdXQgcmVxdWlyZW1lbnRzIG9uIG90aGVyIHByb3RvY29scyB0aGF0IG5p Z2h0IGxvY2sgdGhlIGRhdGFiYXNlPw0KQmFsYXpzOiBNeSB2aWV3IGlzIGlmIHNvbWV0aGluZyBp cyBsb2NrZWQgbGV0IGl0IGFzIGl0IGlzLg0KRGlzY3Vzc2lvbiBvZiB3aGV0aGVyIHBhcnRpYWwg bG9ja3MgaW1wb3NlcyBiZWhhdmlvcmFsIGRpZmZlcmVuY2VzIG9uIG90aGVyIHByb3RvY29scy4N CkRhdmU6IGhvdyB3aWxsIGEgTkVUQ09ORiBsb2NrIGltcGFjdCBTTk1QPyBJZiB5b3UgcHV0IGEg cGFydGlhbCBsb2NrIG9uIE5FVENPTkYgdGhhdCBjb3ZlcnMgdW5kZXJseWluZyBpbnN0cnVtZW50 YXRpb24uIFRoZSBsb2NrIG1pZ2h0IGltcGFjdCBTTk1QIHRyYW5zYWN0aW9ucyBhbmQgZXJyb3Ig Y29kZXMuDQpTTk1QIGlzIG5vdCBwcmVwYXJlZCB0byBoYW5kbGUgdGhpcyBraW5kIG9mIGlzc3Vl cy4NCkJhbGF6czogd2UgYWxyZWFkeSBoYXZlIHRoaXMgcmVxdWlyZW1lbnQgZm9yIHRoZSBnbG9i YWwgbG9jazsgdGhlcmUgaXMgbm90aGluZyBuZXcuDQpEYXZpZCBQOiBZb3UnbGwgZ2V0IGEgbm90 IHdyaXRhYmxlIG9yIHJlc291cmNlLXVuYXZhaWxhYmxlIGVycm9yIGZyb20gU05NUA0KV2VzIEhh cmRhY2tlcjogSXQncyBlYXN5IHRvIGNoZWNrIHBhcnRpYWwgbG9ja3MgaWYgdGhlIGRhdGEgbW9k ZWwgYmV0d2VlbiB2YXJpb3VzIGRhdGEgbW9kZWwgbGFuZ3VhZ2VzIHdvcmsgd2VsbC4gSWYgdGhl IGFwcHJvYWNoIHRvIG1vZGVsaW5nIGlzIGRpc3NpbWlsYXIgYmV0d2VlbiBpbnRlcmZhY2VzLCB0 aGlzIGlzIGRpZmZpY3VsdCB0byBkby4gRm9yIGdsb2JhbCBsb2NrcywgdGhpcyBpcyBlYXN5IJYg aWYgbG9ja2VkLCBwcmV2ZW50IGFsbCBzZXRzLiBUbyBkbyB0aGlzIGZvciByZXF1aXJpbmcgYW55 dGhpbmcgbWF5IG1vZGlmeSBhbnl0aGluZyBJIHN1c3BlY3QgdGhlIHJlc3VsdCB3aWxsIGJlIHBl b3BsZSB3b24ndCBmb2xsb3cgaXQuIEJ1dCBmb3IgcGFydGlhbCBsb2NrcywgaWYgaW50ZXJmYWNl IG1vZGVscyBkaWZmZXJlbnRseSwgaXQgY2FuIGJlIHZlcnkgZXhwZW5zaXZlIHRvIGltcGxlbWVu dC4gQ2hlY2tpbmcgcGFydGlhbCBsb2NrcyBhY3Jvc3MgbWFuYWdlbWVudCBpbnRlcmZhY2VzIHdp bGwgYmUgZGlmZmljdWx0IC0gaG93IGxpa2VseSB3aWxsIHRoaXMgaW1wbGVtZW50ZWQgY29ycmVj dGx5Pw0KU2hhcm9uOiBJIHRoaW5rIHdoYXQgd2UgYXJlIHRhbGtpbmcgYWJvdXQgYXJlIGZ1bmRh bWVudGFsIHJlcXVpcmVtZW50cy4gVGhpcyBpcyBhIHBlcmZlY3RseSByZWFzb25hYmxlIHJlcXVp cmVtZW50IHRvIENMSSB0aGF0IGl0IHJlc3BlY3RzIHBhcnRpYWxsIGxvY2tzIGFuZCB3ZSBkZWZp bml0ZWx5IGtlZXAgdGhvc2UuDQpCYWxhenM6IFRoZXJlIGFyZSB0d28gbGV2ZWxzIG9mIHN1cHBv cnQgZm9yIHBhcnRpYWwgbG9ja2luZyB0aGF0IHdlIG1pZ2h0IHJlcXVpcmUgZm9ybSBDTEkgb3Ig U05NUC4gV2UgcmVxdWlyZSB0aGVtIGFzIHdyaXR0ZW4gdGhhdCB0aGV5IG11c3Qgbm90IG1vZGlm eSBzdHVmZi4gV2UgZG9uJ3QgcmVxdWlyZSB0aGVtIHRvIGRvIHRoZW1zZWx2ZXMgcGFydGlhbCBs b2NraW5nLg0KV2VzOiBQZW9wbGUgZGlkIG5vdCBmb2xsb3cgdGhlIGF0b21pYyBzZXQgbW9kZWwg YmVjYXVzZSBpdCB3YXMgZXhwZW5zaXZlLiANCkRhdmlkIFA6IEEgbG90IG9mIHBlb3BsZSBkbyBT Tk1QIGF0b21pYyBzZXRzIGNvcnJlY3RseS4NCkRhdmlkIFA6IFRoaXMgaXMgYW4gb3B0aW9uYWwg dGhpbmcsIGl0J3MgYSBjYXBhYmlsaXR5LiBJZiB5b3UgY2hvb3NlIHRvIGltcGxlbWVudCBpdCBp dCdzIGdvbm5hIGNvc3Qgc29tZXRoaW5nLiBJIHRoaW5rIHRoYXQgd2UgYWJzb2x1dGVseSBzaG91 bGQgZG8gdGhhdC4NCkJlcnQ6IEkgc3VnZ2VzdCB5b3UgZ28gYWhlYWQgd2hhdCB5b3VyIHBsYW4g d2FzIHRvIGRvIHRoYXQgb3RoZXIgcHJvdG9jb2xzIG5lZWQgdG8gaG9ub3IgdGhlIGxvY2suIEZv ciBub3csIHdlIGtlZXAgdGhlIHByb3Bvc2VkIHJlc29sdXRpb24uIFdHTEMgbWlnaHQgYnJpbmcg c29tZSBjb21tZW50cywgd2UnbGwgZGVhbCB3aXRoIHRoZW0gYXMgd2Ugc2VlIHRoZW0uIEtlZXAg YWxzbyB0aGUgZW1wdHkgbG9ja3MgYXMgaXQgaXMgaW4gdGhlIGRvY3VtZW50Lg0KQmVydDogSXMg dGhlIGRvY3VtZW50IHJlYWR5IGZvciBXRyBsYXN0IGNhbGw/DQo4IGluIGZhdm9yLCBubyBvYmpl Y3Rpb25zLCBwbGFuIGZvciBXR0xDIGluIEF1Z3VzdC4NCg0KDQpORVRDT05GIG92ZXIgVExTIChN b2hhbWFkIEJhZHJhKQ0KDQpTbGlkZXM6IGh0dHA6Ly93d3czLmlldGYub3JnL3Byb2NlZWRpbmdz LzA4anVsL3NsaWRlcy9uZXRjb25mLTIucHB0DQoNCk1vaGFtYWQgQmFkcmEgcHJlc2VudHMgdGhl IFRMUyB0cmFuc3BvcnQgZHJhZnQNClNlY3VyaXR5IEFEIFRpbSBQb2xrOiBJbiBnZW5lcmFsIHdl IGRvbid0IGhhdmUgYW55IGJpZyBwcm9ibGVtIHVzaW5nIFRMUyBhcyB0aGUgc2VjdXJpdHkgdHJh bnNwb3J0LiBHaXZlbiB0aGUgc2V0IG9mIHBhc3N3b3JkIGJhc2VkIHNlY3VyaXR5IHRyYW5zcG9y dHMgYWxyZWFkeSBhdmFpbGFibGUgZm9yIE5FVENPTkYsIHdlIGRvbid0IHVuZGVyc3RhbmQgd2hh dCB0aGUgVExTIHZlcnNpb24gaXMgYWRkaW5nIHRvIHRoZSBtaXggZm9yIE5FVENPTkYuDQpUaW0g UG9sazogV2Ugc2VlIGlmIHlvdSBhcmUgdXNpbmcgY2VydGlmaWNhdGUtYmFzZWQgbXV0dWFsIGF1 dGhlbnRpY2F0aW9uIHRoaXMgaXMgc29tZXRoaW5nIG5ldyBhbmQgcmVhbGx5IGltcG9ydGFudCB0 aGF0IHlvdSdkIGJlIGFibGUgdG8gZG8gZm9yIE5FVENPTkYgb3ZlciBUTFMgdGhhdCdzIHNvbWV0 aGluZyByZWFsbHkgbm90IGhhdmUgZWxzZXdoZXJlLiBXZSB1bmRlcnN0YW5kIHdoeSB5b3UgZG8g dGhlIG5vbi1zdGFuZGFyZCBoYW5kbGluZyBvZiBwYXNzd29yZHMsIGl0IGlzIG5vdCBjbGVhciB3 aGF0IHRoZSBhY3R1YWwgdmFsdWUgaXMgZ2l2ZW4gdGhlIGZhY3QgdGhhdCB5b3UgY2FuJ3QgdXNl IG9mZiB0aGUgc2hlbGYgVExTIGltcGxlbWVudGF0aW9ucyBhbnltb3JlLg0KVGltIFBvbGs6IEFy ZSB5b3Ugc2ltcGx5IGFkZGluZyBjb25mdXNpb24gYnkgYWRkaW5nIGFub3RoZXIgcGFzc3dvcmQg YmFzZWQgdHJhbnNwb3J0PyBXZSBsaWtlIHRoZSBjZXJ0aWZpY2F0ZSBiYXNlZCBhdXRoZW50aWNh dGlvbi4NClRpbSBQb2xrOiBUbyB3aGF0IGV4dGVuZCBpcyB0aGlzIGFsaWduZWQgdG8gdGhlIFNZ U0xPRyBvZiBUTFMgYXBwcm9hY2g/DQpUaW0gUG9sazogVXNpbmcgVExTIGFzIG11Y2ggYXMgcG9z c2libGUgb3V0IG9mIHRoZSBib3ggbWlnaHQgaGFzIHRoZSBtb3N0IHZhbHVlLg0KQmVydDogV2hh dCB2YWx1ZSBkb2VzIFRMUyBhZGQgYXMgYSB0cmFuc3BvcnQ/IEEgbnVtYmVyIG9mIHBlb3BsZSBp biBWYW5jb3V2ZXIgd2hvIGFjdHVhbGx5IHN1cHBvcnRlZCwgdGhhdCB0aGlzIHdhcyBhIGdvb2Qg YWRkaXRpb24uIFRoZXJlIGFyZSBhcGFyZW50bHkgZW52aXJvbm1lbnRzIHdoZXJlIHBlb3BsZSBo YXZlIFRMUyBpbiB0aGVyZSBzeXN0ZW1zIGFuZCBtYXkgbm90IGhhdmUsIHlvdSBrbm93LCBzb21l IG9mIHRoZSBvdGhlciBwcm90b2NvbHMuDQpUaW0gUG9sazogRm9yIHRob3NlIGVudmlyb25tZW50 cyB0aGF0IGhhdmUgY2VydGlmaWNhdGVzIGRlcGxveWVkLCBhIGNlcnRpZmljYXRlIGJhc2VkIFRM UyB0cmFuc3BvcnQgbWFrZXMgc2Vuc2UuIA0KQmFkcmE6IEkgYW0gc2ltcGx5IGdlbmVyYXRpbmcg YSBwcmUtc2hhcmVkIGtleSBQU0suDQpUaW0gUG9sazogVGhpcyBpcyBqdXN0IGVhcmx5IGZlZWRi YWNrIGZyb20gYSBxdWljayByZXZpZXcgb2YgdGhlIHNwZWNzLCB0aGUgdGV4dCBwcm9iYWJseSBp cyBub3QgY2xlYXIgZW5vdWdoIHlldC4NCkFEIERhbiBSb21hc2NhbnU6IElzIHRoZXJlIGEgVExT IGV4cGVydCBhdmFpbGFibGUgdG8gbG9vayBhdCB0aGlzIGRvY3VtZW50Pw0KVGltIFBvbGs6IFNT SCBhbHJlYWR5IHByb3ZpZGVzIGEgZ29vZCBwYXNzd29yZC1iYXNlZCBzZWN1cmUgdHJhbnNwb3J0 LCBzbyBpdCBpcyBub3QgY2xlYXIgd2hpY2ggdmFsdWUgcHJvcG9zaXRpb24gcGFzc3dvcmQtYmFz ZWQgVExTIGhhcy4gIFdlIGRvIG5vdCBzZWUgc29tZXRoaW5nIGluaGVyZW50bHkgYnJva2VuIHNv IGZhciBmcm9tIGEgaGlnaCBsZXZlbCByZXZpZXcuIFNlYyBBRCBQYXNpIEVyb25lbiBpcyBsaWtl bHkgdG8gbWFrZSBtb3JlIGNvbW1lbnRzIGluIHRoZSBmdXR1cmUuIFdoYXQgaXMgdGhlIG1vdGl2 YXRpb24gZm9yIGRvaW5nIHRoaXM/DQpEYXZlOiBTZWVzIHZhbHVlIGluIFRMUy4gT25jZSB0aGVy ZSBpcyBhY2Nlc3MgY29udHJvbCBpbiBORVRDT05GLCB3ZSBtaWdodCBuZWVkIGFuIGF1dGhlbnRp Y2F0ZWQgdXNlciBpZGVudGl0eS4NCkr8cmdlbjogRGlzdGluZ3Vpc2ggYmV0d2VlbiBjZXJ0LWJh c2VkIFRMUyBhbmQgcGFzc3dvcmQtYmFzZWQgVExTIGluIGEgV0cgbGFzdCBjYWxsLg0KPT4gQmFk cmEgdG8gdGFrZSB0aGUgY29tbWVudHMgb2Ygc2VjdXJpdHkgQURzLCBwZXJoYXBzIG1vcmUgZm9j dXMgb24gY2VydGlmaWNhdGUgYmFzZWQgYXV0aGVudGljYXRpb24sIGNoZWNrIHdpdGggdGhlIFdH Lg0KDQoNCk5FVENPTkYgTm90aWZpY2F0aW9uIENvbnRlbnQgKFNoYXJvbiBDaGlzaG9sbSkNCg0K U2xpZGVzOiBodHRwOi8vd3d3My5pZXRmLm9yZy9wcm9jZWVkaW5ncy8wOGp1bC9zbGlkZXMvbmV0 Y29uZi00LnBwdA0KDQpTaGFyb24gcHJlc2VudHMgbm90aWZpY2F0aW9uIGNvbnRlbnQgc2xpZGVz DQpJc3N1ZSAjMTogY29uZmlndXJhdGlvbiBjaGFuZ2UgZXZlbnRzDQpJc3N1ZSAjMjogc29mdHdh cmUgY2hhbmdlIGluZGljYXRpb24NClNoYXJvbjogQWRkIHRoaXMgd29yayB0byB0aGUgY2hhcnRl ciBhcyBzdGFuZGFyZHMtdHJhY2sgZG9jdW1lbnQ/DQpNZWhtZXQ6IFdoeSBpcyB0aGlzIHN0YW5k YXJkcyB0cmFjayBkb2N1bWVudD8gRG9lcyBpdCBoYXZlIHRvIGJlPw0KU2hhcm9uOiBXZSB0eXBp Y2FsbHkgcHV0IE1JQiBtb2R1bGVzIG9uIHN0YW5kYXJkcyB0cmFjazsgdGhpcyBpcyBzaW1pbGFy DQpEYW46IEkgZG9uJ3QgdGhpbmsgd2UgaGF2ZSBzb21ldGhpbmcgaW4gdGhlIGNoYXJ0ZXIgdG8g Y292ZXIgdGhpcyB3b3JrLg0KQmVydDogSG93IGlzIGludGVyZXN0IG9mIGRvaW5nIHNvbWUgd29y ayBvbiBtaW5pbWFsIG5vdGlmaWNhdGlvbiBjb250ZW50PyA3LTggaW4gZmF2b3IsIG5vIG9iamVj dGlvbnMNCkRhbjogSSBiZWxpZXZlIHdlIG5lZWQgYSByZWNoYXJ0ZXIgZm9yIHRoaXMuIEl0IGlz IGFkZGluZyBleHRyYSBmdW5jdGlvbmFsaXR5IGJleW9uZCB0aGUgY29uZmlnIGZ1bmN0aW9uIHRo YXQgaXMgdGhlIGJhc2lzIG9mIHRoZSBwcm90b2NvbC4NCkRhdmlkIFA6IEkgbmVlZCB0byBzZWUg dGhlIGNoYXJ0ZXIgdGV4dCBiZWZvcmUgSSBjYW4gYmUgaW4gZmF2b3Igb3IgYWdhaW5zdCBpdC4N CkJlcnQ6IEl0IGxvb2tzIGxpa2Ugd2UgY2Fubm90IGFjY2VwdCBhcyBXRyBpdGVtIG5vdy4gSXQg bG9va3MgYXMgaWYgdGhlIFdHIGlzIHdpbGxpbmcgdG8gY29uc2lkZXIgd29yayBvbiBzb21lIG5v dGlmaWNhdGlvbiBjb250ZW50LCBidXQgdGhhdCB3ZSBmaXJzdCBuZWVkIHRvIGFncmVlIG9uIG5l dyBjaGFydGVyIHRleHQgdGhhdCBjbGVhcmx5IHNwZWxscyBvdXQgd2hhdCB3ZSB3aWxsIG9yIHdp bGwgbm90IGluY2x1ZGUuDQo9PiBDaGFpcnMgd2lsbCBwdXQgdGhpcyB1cCBvbiB0aGUgbWFpbGlu ZyBsaXN0IGFuZCBhc2sgd2hldGhlciB0aGVyZSBpcyBzdXBwb3J0IHRvIHN0YXJ0IHdvcmsgb24g bmV0Y29uZiBjb250ZW50Lg0KDQoNCg== ------_=_NextPart_001_01C8FAD5.8AABD85E Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------_=_NextPart_001_01C8FAD5.8AABD85E-- From netconf-bounces@ietf.org Sun Aug 10 03:49:26 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5B53A6B24; Sun, 10 Aug 2008 03:49:26 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E0C3A6B02 for ; Sun, 10 Aug 2008 03:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vi3PPWtBNiwi for ; Sun, 10 Aug 2008 03:49:23 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 3EB003A6B24 for ; Sun, 10 Aug 2008 03:49:21 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m7AAelUS008901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 10 Aug 2008 12:40:47 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m7AAel1F025509 for ; Sun, 10 Aug 2008 12:40:47 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 10 Aug 2008 12:40:47 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8FAD5.8AABD85E" Date: Sun, 10 Aug 2008 12:40:44 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Minutes of the Netconf Session at IETF 72 Thread-Index: Acj61YlPJDPDcXRhQlSOkIuGFqCwxQ== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 10 Aug 2008 10:40:47.0640 (UTC) FILETIME=[8CBF8980:01C8FAD5] Subject: [Netconf] Draft Minutes of the Netconf Session at IETF 72 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8FAD5.8AABD85E Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C8FAD5.8AABD85E" ------_=_NextPart_002_01C8FAD5.8AABD85E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All,=20 attached are the draft minutes for the Netconf Session=20 at IETF 72 we have prepared from the notes of the minute=20 takers (many thanks again to Juergen and David H. for=20 taking notes!! :)=20 <>=20 Please send us your change requests or corrections by=20 25th of August. We'll put it to the meeting materials site=20 as the preliminary version.=20 Thank you.=20 Bert & Mehmet=20 ------_=_NextPart_002_01C8FAD5.8AABD85E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Draft Minutes of the Netconf Session at IETF 72

Hi All,
attached are the = draft minutes for the Netconf Session
at IETF 72 we have prepared from the notes of the minute
takers (many thanks again to Juergen and David H. for
taking notes!! :)
= <<Draft_IETF72-Netconf-Minutes.txt>>
Please send us = your change requests or corrections by
25th of August. We'll put it to the meeting materials site
as the preliminary version. =
Thank = you.
Bert & Mehmet =

------_=_NextPart_002_01C8FAD5.8AABD85E-- ------_=_NextPart_001_01C8FAD5.8AABD85E Content-Type: text/plain; name="Draft_IETF72-Netconf-Minutes.txt" Content-Transfer-Encoding: base64 Content-Description: Draft_IETF72-Netconf-Minutes.txt Content-Disposition: attachment; filename="Draft_IETF72-Netconf-Minutes.txt" DQotLS0gUHJlbGltaW5hcnkgIC0gQXVndXN0IDEwLCAyMDA4IC0tLQ0KDQpNaW51dGVzIG9mIHRo ZSBOZXR3b3JrIENvbmZpZ3VyYXRpb24gV0cgU2Vzc2lvbiBhdCB0aGUgSUVURiAjNzIsIER1Ymxp biwgSXJlbGFuZCANClRVRVNEQVksIEp1bHkgMjksIDIwMDggMTg1MC0xOTUwIA0KDQpXRyBDaGFp cnM6IA0KQmVydCBXaWpuZW4gPGJlcnRpZXRmQGJ3aWpuZW4ubmV0PiANCk1laG1ldCBFcnN1ZSA8 bWVobWV0LmVyc3VlQG5zbi5jb20+IA0KQUQ6IERhbiBSb21hc2NhbnUNClNlY3VyaXR5IEFEOiBU aW0gUG9saw0KDQpUaGFuayB5b3UgdG8gdGhlIG1pbnV0ZSB0YWtlcnM6DQpKdWVyZ2VuIFNjaG9l bndhZWxkZXIsIERhdmlkIEhhcnJpbmd0b24NCg0KQWdlbmRhIGFuZCBXRyBzdGF0dXMgc2xpZGVz OiBodHRwOi8vd3d3My5pZXRmLm9yZy9wcm9jZWVkaW5ncy8wOGp1bC9zbGlkZXMvbmV0Y29uZi0w LnBwdA0KDQpUaGVyZSB3ZXJlIDM1IHBlcnNvbnMgaW4gdGhlIE5FVENPTkYgc2Vzc2lvbi4NCg0K QmVydCBXaWpuZW4gdGFrZXMgY2FyZSBvZiB0aGUgYWRtaW5pc3RyaXZpYS4NCg0KV0cgc3RhdHVz IHJldmlldyBnaXZlbiBieSBNZWhtZXQgRXJzdWUuDQpORVRDT05GIE5vdGlmaWNhdGlvbiBkcmFm dCBoYXMgYmVlbiBwdWJsaXNoZWQgYXMgUkZDIDUyNzcuDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpORVRDT05GIE1v bml0b3JpbmcgU2NoZW1hIChNYXJrIFNjb3R0ICkNCg0KU2xpZGVzOiBodHRwOi8vd3d3My5pZXRm Lm9yZy9wcm9jZWVkaW5ncy8wOGp1bC9zbGlkZXMvbmV0Y29uZi0xLnBwdA0KIA0KTWFyayBTY290 dCBwcmVzZW50cyB0aGUgbW9uaXRvcmluZyBzbGlkZXMNCklzc3VlICMxOiBXaGljaCB0ZXJtaW5v bG9neSBzaG91bGQgYmUgdXNlZD8gc2NoZW1hIG9yIG1vZGVsIG9yIGRhdGEgbW9kZWwgLi4uPw0K RGF2ZSBIYXJyaW5ndG9uOiB3ZSB1c2VkIHRvIG1ha2UgYSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGRh dGEgbW9kZWxzIGFuZCBpbmZvcm1hdGlvbiBtb2RlbHMNCkRhdmlkIFBhcnRhaW46IGluIFlBTkcs IHdlIGNhbGwgdGhpbmdzIGRhdGEgbW9kZWxzIG9yIG1vZHVsZXMNClNoYXJvbiBDaGlzaG9sbTog aW4gWE1MIHdvcmxkLCBwZW9wbGUgdXNlIHRoZSB0ZXJtIHNjaGVtYQ0KUGhpbCBTaGFmZXI6IHNp bmNlIHRoaXMgaXMgbm90IFhTRCBvbmx5LCB3aHkgbm90IHVzZSBkYXRhIG1vZGVsDQpEYXZlOiBS RkMgMzQ0NCBzaG91bGQgYmUgY2hlY2tlZCB3aGV0aGVyIGl0IGFwcGxpZXMNCkRhdmlkIFA6IHBy ZWZlciBkYXRhIG1vZGVsDQpNYXJ0aW4gQmpvcmtsdW5kOiBXaGF0IGFib3V0IHRoZSBnZXQtc2No ZW1hIFJQQz8NCkJlcnQ6IFRoYXRzIGNvbnNpc3RlbnQgd2l0aCB0aGUgTkVUQ09ORiBkb2N1bWVu dHMgYW5kIHdlIHNob3VsZCBjb25pdG51ZSB3aXRoIHRoYXQgcmlnaHQ/DQpCZXJ0OiBJIHRoaW5r IHRoaXMgaGFzIG5vdCBiZWVuIGRpc2N1c3NlZCBvbiB0aGUgbWFpbGxpc3QgeWV0LiBXZSdsbCB0 cnkgdG8gcmVhY2ggY29uc2Vuc3VzIG9uIHRoZSBtYWlsbGlzdCBvbiB0aGF0Lg0KPT4gcHV0IHVw IG9uIHRoZSBtYWlsaW5nIGxpc3QgdG8gc2VlIHdoZXJlIHRoZXJlIGlzIGNvbnNlbnN1cw0KSXNz dWUgIzI6IGxhY2sgb2YgYWdyZWVkIFhTRCBkZWZpbml0aW9ucyBmb3IgZGF0YSB0eXBlcyB0byB1 c2UuDQpNYXJrOiBIb3cgZG9lcyB0aGlzIGRpc2N1c3Npb24gaW1wYWN0IGN1cnJlbnQgd29yayB0 byBzdGFuZGFyZGl6ZSBjb250ZW50Pw0KRGF2ZTogT1BTQVdHIHdvcmtzIG9uIFNNSXYyIHRyYW5z bGF0aW9ucyB0byBYU0QuIElmIHlvdSB3YW50IHRvIGRpc2N1c3MgdGhpcyB3b3JrLCB0aGlzIGNh biBiZSBkb25lIGluIHRoYXQgd29ya2dyb3VwLg0KTWFyazogRm9yIHRob3NlIHRoYXQgYXJlIGFs cmVhZHkgYmVpbmcgY292ZXJlZCBpbiBCb2IncyB3b3JrIHdlIGNhbiB1c2UgdGhvc2UgYXMgaXMg YnV0IGluIGNhc2Ugd2Ugd2FudCBhIGRpZmZlcmVudCBkYXRhIHR5cGUgb3IgYW4gZW5oYW5jZWQg ZGF0YSB0eXBlIHRoYXQncyBub3QgY292ZXJlZCBieSBCb2IncyB3b3JrLiBUaGVyZSBhcmUgc3Rp bGwgY29tcGxleCBkYXRhIHR5cGVzIHdoaWNoIHdlIG5lZWQuIEFyZSB3ZSBkZWZpbmluZyB0aGVt IG5vdyBhbmQgdXNlPw0KRGF2aWQgUDogQm9iIE5hdGFsZSwgSvxyZ2VuIFNjaPZud+RsZGVyLCBN YXJrIHNob3VsZCBzaXQgZG93biBhbmQgZmlndXJlIG91dCBhIGdvb2Qgd2F5IGZvcndhcmQgYW5k IHByb3Bvc2UgaXQgdG8gdGhlIGxpc3QsIGNyb3NzLXBvc3QgdG8gT1BTIGFyZWEgd29ya2dyb3Vw Lg0KTWFyazogSXMgdGhhdCBiZWNhdXNlIHdlIGhhdmUgYWdyZWVkIHRoYXQgd2UgbXVzdCBoYXZl IGludHJpbnNpY2x5IHRoZSBzYW1lIGRhdGEgdHlwZXMgYXMgZGVmaW5lZCBpbiBCb2IncyB3b3Jr Pw0KQmVydDogV2UgZGlkIG5vdCBhZ3JlZSBidXQgd2Uga25vdyB0aGVyZSBpcyBzaW1pbGFyIHdv cmssIHNwZWFrIHdpdGggdGhvc2UgcGVvcGxlIGFuZCB0cnkgdG8gY29tZSB1cCB3aXRoIG9uZSBz b2x1dGlvbi4NCkRhdmU6IE9QU0FXRyBpcyBkaWZmZXJlbnQgZnJvbSB3aGF0IHlvdSBhcmUgZG9p bmcgaGVyZSwgaXQgaXMgb25seSBkZWFsaW5nIHdpdGggU01JdjItPiBYU0QgdHJhbnNsYXRpb24u IFRoaXMgaXMgbm90IHRoZSBzYW1lIHdvcmsgaXQgaGFzIGEgZGlmZmVyZW50IGZva3VzDQpNYXJr OiBBcmd1YWJseSBtb3JlIGRhdGEgdHlwZXMgbWlnaHQgY29tZSB1cCBhcyB3ZSBkZWZpbmUgbW9y ZSBjb250ZW50LiBXaGVuIHNvbWVvbmUgZGVmaW5lcyBORVRDT05GIGNvbnRlbnQgYXJlIHdlIGF0 IGxlYXN0IHdpdGhpbiB0aGUgTkVUQ09ORiBjb250ZXh0IGdvaW5nIHRvIHVzZSBpdC4NCkr8cmdl bjogV2l0aCBZQU5HL05FVENPTkYsIHdlIGhhdmUgYSBjaGlja2VuIGFuZCBlZ2cgcHJvYmxlbS4g V2UgY2FuIG9ubHkgc29sdmUgdGhpcyBieSBtYWtpbmcgYSBiZXN0IGd1ZXNzIGFuZCBnbyBhaGVh ZDsgbW9yZSBnZW5lcmFsIHF1ZXN0aW9uIGlzIHdoYXQgaGFwcGVucyBpZiB5b3UgZG8gZGlmZmVy ZW50IFNNSXYyIHRyYW5zbGF0aW9ucy4gU01JdjItPi4uLi0+WFNEIGlzc3VlIGlzIG5vdCBhIHBy b2JsZW0gdG8gYmUgc29sdmVkIGluIHRoaXMgV0cNCkJlcnQ6IEJlZm9yZSBXR0xDIHdlIHNob3Vs ZCB0aGluayBvbiB0aGVzZSBpc3N1ZXMuDQo9PiBUaGUgaXNzdWUgd2lsbCBiZSBicm91Z2h0IHRv IHRoZSBtYWlsaW5nIGxpc3QuDQoNCg0KUGFydGlhbCBMb2NrIFJQQyBmb3IgTkVUQ09ORiAoQmFs YXpzIExlbmd5ZWwpDQoNClNsaWRlczogaHR0cDovL3d3dzMuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv MDhqdWwvc2xpZGVzL25ldGNvbmYtMy5wcHQNCg0KQmFsYXpzIExlbmd5ZWwgcHJlc2VudHMgdGhl IGxvY2tpbmcgZHJhZnQNCklzc3VlICMxOiByZW1vdmUgZW1wdHkgbG9ja3M/DQpCYWxhenM6IHBy b3Bvc2FsIHRvIGtlZXAgZW1wdHkgbG9ja3MgZm9yIGNvbnNpc3RlbmN5IHJlYXNvbnMuIA0KSXNz dWUgIzI6IE5lZWQgdG8gYWRkIHNvbWUgY2xhcmlmaWNhdGlvbnMgdGhhdDogRG9lcyB0aGUgZ3Jh bnVsYXIgbG9ja2luZyBwdXQgcmVxdWlyZW1lbnRzIG9uIG90aGVyIHByb3RvY29scyB0aGF0IG5p Z2h0IGxvY2sgdGhlIGRhdGFiYXNlPw0KQmFsYXpzOiBNeSB2aWV3IGlzIGlmIHNvbWV0aGluZyBp cyBsb2NrZWQgbGV0IGl0IGFzIGl0IGlzLg0KRGlzY3Vzc2lvbiBvZiB3aGV0aGVyIHBhcnRpYWwg bG9ja3MgaW1wb3NlcyBiZWhhdmlvcmFsIGRpZmZlcmVuY2VzIG9uIG90aGVyIHByb3RvY29scy4N CkRhdmU6IGhvdyB3aWxsIGEgTkVUQ09ORiBsb2NrIGltcGFjdCBTTk1QPyBJZiB5b3UgcHV0IGEg cGFydGlhbCBsb2NrIG9uIE5FVENPTkYgdGhhdCBjb3ZlcnMgdW5kZXJseWluZyBpbnN0cnVtZW50 YXRpb24uIFRoZSBsb2NrIG1pZ2h0IGltcGFjdCBTTk1QIHRyYW5zYWN0aW9ucyBhbmQgZXJyb3Ig Y29kZXMuDQpTTk1QIGlzIG5vdCBwcmVwYXJlZCB0byBoYW5kbGUgdGhpcyBraW5kIG9mIGlzc3Vl cy4NCkJhbGF6czogd2UgYWxyZWFkeSBoYXZlIHRoaXMgcmVxdWlyZW1lbnQgZm9yIHRoZSBnbG9i YWwgbG9jazsgdGhlcmUgaXMgbm90aGluZyBuZXcuDQpEYXZpZCBQOiBZb3UnbGwgZ2V0IGEgbm90 IHdyaXRhYmxlIG9yIHJlc291cmNlLXVuYXZhaWxhYmxlIGVycm9yIGZyb20gU05NUA0KV2VzIEhh cmRhY2tlcjogSXQncyBlYXN5IHRvIGNoZWNrIHBhcnRpYWwgbG9ja3MgaWYgdGhlIGRhdGEgbW9k ZWwgYmV0d2VlbiB2YXJpb3VzIGRhdGEgbW9kZWwgbGFuZ3VhZ2VzIHdvcmsgd2VsbC4gSWYgdGhl IGFwcHJvYWNoIHRvIG1vZGVsaW5nIGlzIGRpc3NpbWlsYXIgYmV0d2VlbiBpbnRlcmZhY2VzLCB0 aGlzIGlzIGRpZmZpY3VsdCB0byBkby4gRm9yIGdsb2JhbCBsb2NrcywgdGhpcyBpcyBlYXN5IJYg aWYgbG9ja2VkLCBwcmV2ZW50IGFsbCBzZXRzLiBUbyBkbyB0aGlzIGZvciByZXF1aXJpbmcgYW55 dGhpbmcgbWF5IG1vZGlmeSBhbnl0aGluZyBJIHN1c3BlY3QgdGhlIHJlc3VsdCB3aWxsIGJlIHBl b3BsZSB3b24ndCBmb2xsb3cgaXQuIEJ1dCBmb3IgcGFydGlhbCBsb2NrcywgaWYgaW50ZXJmYWNl IG1vZGVscyBkaWZmZXJlbnRseSwgaXQgY2FuIGJlIHZlcnkgZXhwZW5zaXZlIHRvIGltcGxlbWVu dC4gQ2hlY2tpbmcgcGFydGlhbCBsb2NrcyBhY3Jvc3MgbWFuYWdlbWVudCBpbnRlcmZhY2VzIHdp bGwgYmUgZGlmZmljdWx0IC0gaG93IGxpa2VseSB3aWxsIHRoaXMgaW1wbGVtZW50ZWQgY29ycmVj dGx5Pw0KU2hhcm9uOiBJIHRoaW5rIHdoYXQgd2UgYXJlIHRhbGtpbmcgYWJvdXQgYXJlIGZ1bmRh bWVudGFsIHJlcXVpcmVtZW50cy4gVGhpcyBpcyBhIHBlcmZlY3RseSByZWFzb25hYmxlIHJlcXVp cmVtZW50IHRvIENMSSB0aGF0IGl0IHJlc3BlY3RzIHBhcnRpYWxsIGxvY2tzIGFuZCB3ZSBkZWZp bml0ZWx5IGtlZXAgdGhvc2UuDQpCYWxhenM6IFRoZXJlIGFyZSB0d28gbGV2ZWxzIG9mIHN1cHBv cnQgZm9yIHBhcnRpYWwgbG9ja2luZyB0aGF0IHdlIG1pZ2h0IHJlcXVpcmUgZm9ybSBDTEkgb3Ig U05NUC4gV2UgcmVxdWlyZSB0aGVtIGFzIHdyaXR0ZW4gdGhhdCB0aGV5IG11c3Qgbm90IG1vZGlm eSBzdHVmZi4gV2UgZG9uJ3QgcmVxdWlyZSB0aGVtIHRvIGRvIHRoZW1zZWx2ZXMgcGFydGlhbCBs b2NraW5nLg0KV2VzOiBQZW9wbGUgZGlkIG5vdCBmb2xsb3cgdGhlIGF0b21pYyBzZXQgbW9kZWwg YmVjYXVzZSBpdCB3YXMgZXhwZW5zaXZlLiANCkRhdmlkIFA6IEEgbG90IG9mIHBlb3BsZSBkbyBT Tk1QIGF0b21pYyBzZXRzIGNvcnJlY3RseS4NCkRhdmlkIFA6IFRoaXMgaXMgYW4gb3B0aW9uYWwg dGhpbmcsIGl0J3MgYSBjYXBhYmlsaXR5LiBJZiB5b3UgY2hvb3NlIHRvIGltcGxlbWVudCBpdCBp dCdzIGdvbm5hIGNvc3Qgc29tZXRoaW5nLiBJIHRoaW5rIHRoYXQgd2UgYWJzb2x1dGVseSBzaG91 bGQgZG8gdGhhdC4NCkJlcnQ6IEkgc3VnZ2VzdCB5b3UgZ28gYWhlYWQgd2hhdCB5b3VyIHBsYW4g d2FzIHRvIGRvIHRoYXQgb3RoZXIgcHJvdG9jb2xzIG5lZWQgdG8gaG9ub3IgdGhlIGxvY2suIEZv ciBub3csIHdlIGtlZXAgdGhlIHByb3Bvc2VkIHJlc29sdXRpb24uIFdHTEMgbWlnaHQgYnJpbmcg c29tZSBjb21tZW50cywgd2UnbGwgZGVhbCB3aXRoIHRoZW0gYXMgd2Ugc2VlIHRoZW0uIEtlZXAg YWxzbyB0aGUgZW1wdHkgbG9ja3MgYXMgaXQgaXMgaW4gdGhlIGRvY3VtZW50Lg0KQmVydDogSXMg dGhlIGRvY3VtZW50IHJlYWR5IGZvciBXRyBsYXN0IGNhbGw/DQo4IGluIGZhdm9yLCBubyBvYmpl Y3Rpb25zLCBwbGFuIGZvciBXR0xDIGluIEF1Z3VzdC4NCg0KDQpORVRDT05GIG92ZXIgVExTIChN b2hhbWFkIEJhZHJhKQ0KDQpTbGlkZXM6IGh0dHA6Ly93d3czLmlldGYub3JnL3Byb2NlZWRpbmdz LzA4anVsL3NsaWRlcy9uZXRjb25mLTIucHB0DQoNCk1vaGFtYWQgQmFkcmEgcHJlc2VudHMgdGhl IFRMUyB0cmFuc3BvcnQgZHJhZnQNClNlY3VyaXR5IEFEIFRpbSBQb2xrOiBJbiBnZW5lcmFsIHdl IGRvbid0IGhhdmUgYW55IGJpZyBwcm9ibGVtIHVzaW5nIFRMUyBhcyB0aGUgc2VjdXJpdHkgdHJh bnNwb3J0LiBHaXZlbiB0aGUgc2V0IG9mIHBhc3N3b3JkIGJhc2VkIHNlY3VyaXR5IHRyYW5zcG9y dHMgYWxyZWFkeSBhdmFpbGFibGUgZm9yIE5FVENPTkYsIHdlIGRvbid0IHVuZGVyc3RhbmQgd2hh dCB0aGUgVExTIHZlcnNpb24gaXMgYWRkaW5nIHRvIHRoZSBtaXggZm9yIE5FVENPTkYuDQpUaW0g UG9sazogV2Ugc2VlIGlmIHlvdSBhcmUgdXNpbmcgY2VydGlmaWNhdGUtYmFzZWQgbXV0dWFsIGF1 dGhlbnRpY2F0aW9uIHRoaXMgaXMgc29tZXRoaW5nIG5ldyBhbmQgcmVhbGx5IGltcG9ydGFudCB0 aGF0IHlvdSdkIGJlIGFibGUgdG8gZG8gZm9yIE5FVENPTkYgb3ZlciBUTFMgdGhhdCdzIHNvbWV0 aGluZyByZWFsbHkgbm90IGhhdmUgZWxzZXdoZXJlLiBXZSB1bmRlcnN0YW5kIHdoeSB5b3UgZG8g dGhlIG5vbi1zdGFuZGFyZCBoYW5kbGluZyBvZiBwYXNzd29yZHMsIGl0IGlzIG5vdCBjbGVhciB3 aGF0IHRoZSBhY3R1YWwgdmFsdWUgaXMgZ2l2ZW4gdGhlIGZhY3QgdGhhdCB5b3UgY2FuJ3QgdXNl IG9mZiB0aGUgc2hlbGYgVExTIGltcGxlbWVudGF0aW9ucyBhbnltb3JlLg0KVGltIFBvbGs6IEFy ZSB5b3Ugc2ltcGx5IGFkZGluZyBjb25mdXNpb24gYnkgYWRkaW5nIGFub3RoZXIgcGFzc3dvcmQg YmFzZWQgdHJhbnNwb3J0PyBXZSBsaWtlIHRoZSBjZXJ0aWZpY2F0ZSBiYXNlZCBhdXRoZW50aWNh dGlvbi4NClRpbSBQb2xrOiBUbyB3aGF0IGV4dGVuZCBpcyB0aGlzIGFsaWduZWQgdG8gdGhlIFNZ U0xPRyBvZiBUTFMgYXBwcm9hY2g/DQpUaW0gUG9sazogVXNpbmcgVExTIGFzIG11Y2ggYXMgcG9z c2libGUgb3V0IG9mIHRoZSBib3ggbWlnaHQgaGFzIHRoZSBtb3N0IHZhbHVlLg0KQmVydDogV2hh dCB2YWx1ZSBkb2VzIFRMUyBhZGQgYXMgYSB0cmFuc3BvcnQ/IEEgbnVtYmVyIG9mIHBlb3BsZSBp biBWYW5jb3V2ZXIgd2hvIGFjdHVhbGx5IHN1cHBvcnRlZCwgdGhhdCB0aGlzIHdhcyBhIGdvb2Qg YWRkaXRpb24uIFRoZXJlIGFyZSBhcGFyZW50bHkgZW52aXJvbm1lbnRzIHdoZXJlIHBlb3BsZSBo YXZlIFRMUyBpbiB0aGVyZSBzeXN0ZW1zIGFuZCBtYXkgbm90IGhhdmUsIHlvdSBrbm93LCBzb21l IG9mIHRoZSBvdGhlciBwcm90b2NvbHMuDQpUaW0gUG9sazogRm9yIHRob3NlIGVudmlyb25tZW50 cyB0aGF0IGhhdmUgY2VydGlmaWNhdGVzIGRlcGxveWVkLCBhIGNlcnRpZmljYXRlIGJhc2VkIFRM UyB0cmFuc3BvcnQgbWFrZXMgc2Vuc2UuIA0KQmFkcmE6IEkgYW0gc2ltcGx5IGdlbmVyYXRpbmcg YSBwcmUtc2hhcmVkIGtleSBQU0suDQpUaW0gUG9sazogVGhpcyBpcyBqdXN0IGVhcmx5IGZlZWRi YWNrIGZyb20gYSBxdWljayByZXZpZXcgb2YgdGhlIHNwZWNzLCB0aGUgdGV4dCBwcm9iYWJseSBp cyBub3QgY2xlYXIgZW5vdWdoIHlldC4NCkFEIERhbiBSb21hc2NhbnU6IElzIHRoZXJlIGEgVExT IGV4cGVydCBhdmFpbGFibGUgdG8gbG9vayBhdCB0aGlzIGRvY3VtZW50Pw0KVGltIFBvbGs6IFNT SCBhbHJlYWR5IHByb3ZpZGVzIGEgZ29vZCBwYXNzd29yZC1iYXNlZCBzZWN1cmUgdHJhbnNwb3J0 LCBzbyBpdCBpcyBub3QgY2xlYXIgd2hpY2ggdmFsdWUgcHJvcG9zaXRpb24gcGFzc3dvcmQtYmFz ZWQgVExTIGhhcy4gIFdlIGRvIG5vdCBzZWUgc29tZXRoaW5nIGluaGVyZW50bHkgYnJva2VuIHNv IGZhciBmcm9tIGEgaGlnaCBsZXZlbCByZXZpZXcuIFNlYyBBRCBQYXNpIEVyb25lbiBpcyBsaWtl bHkgdG8gbWFrZSBtb3JlIGNvbW1lbnRzIGluIHRoZSBmdXR1cmUuIFdoYXQgaXMgdGhlIG1vdGl2 YXRpb24gZm9yIGRvaW5nIHRoaXM/DQpEYXZlOiBTZWVzIHZhbHVlIGluIFRMUy4gT25jZSB0aGVy ZSBpcyBhY2Nlc3MgY29udHJvbCBpbiBORVRDT05GLCB3ZSBtaWdodCBuZWVkIGFuIGF1dGhlbnRp Y2F0ZWQgdXNlciBpZGVudGl0eS4NCkr8cmdlbjogRGlzdGluZ3Vpc2ggYmV0d2VlbiBjZXJ0LWJh c2VkIFRMUyBhbmQgcGFzc3dvcmQtYmFzZWQgVExTIGluIGEgV0cgbGFzdCBjYWxsLg0KPT4gQmFk cmEgdG8gdGFrZSB0aGUgY29tbWVudHMgb2Ygc2VjdXJpdHkgQURzLCBwZXJoYXBzIG1vcmUgZm9j dXMgb24gY2VydGlmaWNhdGUgYmFzZWQgYXV0aGVudGljYXRpb24sIGNoZWNrIHdpdGggdGhlIFdH Lg0KDQoNCk5FVENPTkYgTm90aWZpY2F0aW9uIENvbnRlbnQgKFNoYXJvbiBDaGlzaG9sbSkNCg0K U2xpZGVzOiBodHRwOi8vd3d3My5pZXRmLm9yZy9wcm9jZWVkaW5ncy8wOGp1bC9zbGlkZXMvbmV0 Y29uZi00LnBwdA0KDQpTaGFyb24gcHJlc2VudHMgbm90aWZpY2F0aW9uIGNvbnRlbnQgc2xpZGVz DQpJc3N1ZSAjMTogY29uZmlndXJhdGlvbiBjaGFuZ2UgZXZlbnRzDQpJc3N1ZSAjMjogc29mdHdh cmUgY2hhbmdlIGluZGljYXRpb24NClNoYXJvbjogQWRkIHRoaXMgd29yayB0byB0aGUgY2hhcnRl ciBhcyBzdGFuZGFyZHMtdHJhY2sgZG9jdW1lbnQ/DQpNZWhtZXQ6IFdoeSBpcyB0aGlzIHN0YW5k YXJkcyB0cmFjayBkb2N1bWVudD8gRG9lcyBpdCBoYXZlIHRvIGJlPw0KU2hhcm9uOiBXZSB0eXBp Y2FsbHkgcHV0IE1JQiBtb2R1bGVzIG9uIHN0YW5kYXJkcyB0cmFjazsgdGhpcyBpcyBzaW1pbGFy DQpEYW46IEkgZG9uJ3QgdGhpbmsgd2UgaGF2ZSBzb21ldGhpbmcgaW4gdGhlIGNoYXJ0ZXIgdG8g Y292ZXIgdGhpcyB3b3JrLg0KQmVydDogSG93IGlzIGludGVyZXN0IG9mIGRvaW5nIHNvbWUgd29y ayBvbiBtaW5pbWFsIG5vdGlmaWNhdGlvbiBjb250ZW50PyA3LTggaW4gZmF2b3IsIG5vIG9iamVj dGlvbnMNCkRhbjogSSBiZWxpZXZlIHdlIG5lZWQgYSByZWNoYXJ0ZXIgZm9yIHRoaXMuIEl0IGlz IGFkZGluZyBleHRyYSBmdW5jdGlvbmFsaXR5IGJleW9uZCB0aGUgY29uZmlnIGZ1bmN0aW9uIHRo YXQgaXMgdGhlIGJhc2lzIG9mIHRoZSBwcm90b2NvbC4NCkRhdmlkIFA6IEkgbmVlZCB0byBzZWUg dGhlIGNoYXJ0ZXIgdGV4dCBiZWZvcmUgSSBjYW4gYmUgaW4gZmF2b3Igb3IgYWdhaW5zdCBpdC4N CkJlcnQ6IEl0IGxvb2tzIGxpa2Ugd2UgY2Fubm90IGFjY2VwdCBhcyBXRyBpdGVtIG5vdy4gSXQg bG9va3MgYXMgaWYgdGhlIFdHIGlzIHdpbGxpbmcgdG8gY29uc2lkZXIgd29yayBvbiBzb21lIG5v dGlmaWNhdGlvbiBjb250ZW50LCBidXQgdGhhdCB3ZSBmaXJzdCBuZWVkIHRvIGFncmVlIG9uIG5l dyBjaGFydGVyIHRleHQgdGhhdCBjbGVhcmx5IHNwZWxscyBvdXQgd2hhdCB3ZSB3aWxsIG9yIHdp bGwgbm90IGluY2x1ZGUuDQo9PiBDaGFpcnMgd2lsbCBwdXQgdGhpcyB1cCBvbiB0aGUgbWFpbGlu ZyBsaXN0IGFuZCBhc2sgd2hldGhlciB0aGVyZSBpcyBzdXBwb3J0IHRvIHN0YXJ0IHdvcmsgb24g bmV0Y29uZiBjb250ZW50Lg0KDQoNCg== ------_=_NextPart_001_01C8FAD5.8AABD85E Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------_=_NextPart_001_01C8FAD5.8AABD85E-- From netconf-bounces@ietf.org Sun Aug 10 03:50:46 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D651E3A6B2F; Sun, 10 Aug 2008 03:50:46 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC2C23A6B02 for ; Sun, 10 Aug 2008 03:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4P91yCwFWGo3 for ; Sun, 10 Aug 2008 03:50:44 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 0F0633A6804 for ; Sun, 10 Aug 2008 03:50:43 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m7AAohN1014430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Aug 2008 12:50:43 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m7AAohNa031416; Sun, 10 Aug 2008 12:50:43 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 10 Aug 2008 12:50:43 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 10 Aug 2008 12:50:40 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of the NETCONF WG Session at IETF 72 and Action Points Thread-Index: Acj61u1HAXGQJtkPRI+xVCOenD/i1g== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 10 Aug 2008 10:50:43.0884 (UTC) FILETIME=[F02326C0:01C8FAD6] Subject: [Netconf] Summary of the NETCONF WG Session at IETF 72 and Action Points X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0251020713==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0251020713== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8FAD6.EE1C59C2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8FAD6.EE1C59C2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG,=20 after having sent out the preliminary minutes we need=20 to confirm the results of the NETCONF session. =20 =3D> [Topic owners] please start the necessary discussion=20 or bring the action points "[A-D]n)" to the maillist as soon as possible. Below is the summary of the NETCONF WG session on=20 TUESDAY, July 29, 2008 1850-1950. - We had 35 persons in the 1 hour NETCONF session. - We reviewed the status of the WG - NETCONF Notification draft has been published as=20 RFC 5277. - We went through the chartered WG items andFrom netconf-bounces@ietf.org Sun Aug 10 03:50:46 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D651E3A6B2F; Sun, 10 Aug 2008 03:50:46 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC2C23A6B02 for ; Sun, 10 Aug 2008 03:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4P91yCwFWGo3 for ; Sun, 10 Aug 2008 03:50:44 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 0F0633A6804 for ; Sun, 10 Aug 2008 03:50:43 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m7AAohN1014430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Aug 2008 12:50:43 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m7AAohNa031416; Sun, 10 Aug 2008 12:50:43 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 10 Aug 2008 12:50:43 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 10 Aug 2008 12:50:40 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of the NETCONF WG Session at IETF 72 and Action Points Thread-Index: Acj61u1HAXGQJtkPRI+xVCOenD/i1g== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 10 Aug 2008 10:50:43.0884 (UTC) FILETIME=[F02326C0:01C8FAD6] Subject: [Netconf] Summary of the NETCONF WG Session at IETF 72 and Action Points X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0251020713==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0251020713== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8FAD6.EE1C59C2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8FAD6.EE1C59C2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG,=20 after having sent out the preliminary minutes we need=20 to confirm the results of the NETCONF session. =20 =3D> [Topic owners] please start the necessary discussion=20 or bring the action points "[A-D]n)" to the maillist as soon as possible. Below is the summary of the NETCONF WG session on=20 TUESDAY, July 29, 2008 1850-1950. - We had 35 persons in the 1 hour NETCONF session. - We reviewed the status of the WG - NETCONF Notification draft has been published as=20 RFC 5277. - We went through the chartered WG items and had=2 had=20 a discussion and review of the documents. NETCONF Monitoring Schema (Mark Scott ) The NETCONF Monitoring needs some work before WGLC.=20 Issue #1: Which terminology should be used? schema or=20 model or data model ...? A1) The issue will be discussed on the maillist to try to=20 converge to consensus [Mark]. Issue #2: lack of agreed XSD definitions for data types=20 to use. The work on SMIv2-to-XSD translation in OPSAWG has=20 a different focus and does not solve the problem of=20 additional data types needed in NETCONF.=20 PS: There was additional disscussion on this issue in the=20 OPSAWG. The SMIv2-to-XSD document will be finalized=20 asap to see how it impacts YANG data type usage.=20 It has been proposed to define short-term data type=20 usage for NETCONF based on XSD. A2) The issue will be discussed first by the base=20 players Mark, Dave H, Bob Natale, J=FCrgen Sch=F6nw=E4lder=20 and co-chairs [Mark] A3) and will be brought to the maillist to reach a=20 consensus for the usage of data types in NETCONF [Mark]. Partial Lock RPC for NETCONF (Balazs Lengyel) Issue #1: Remove empty locks? Keep as it is. Issue #2: Does the granular locking put requirements on=20 other protocols that night lock the database? Keep the text in document. The document is ready for WG last call? 8 in favor,=20 no objections. B1) Update the document for clarifications [Balazs, done] B2) Bring the document to WGLC [Chairs] NETCONF over TLS (Mohamad Badra) Security AD Tim Polk does not see the additional value=20 in the document since the password-based SSH transport=20 is already mandatory. Tim Polk does not have any technical=20 objections to the use of TLS out of the box if the WG=20 decided so. The focus in the document should be on=20 certificate-based TLS. C1) Summarize the WG discussion and take the comments=20 of the security ADs Pasi Eronen and Tim Polk [Badra, mail sent]. C2) Bring AD comments to the maillist and ask for consensus=20 [Badra]. NETCONF Notification Content (Sharon Chisholm) The WG has interest of doing some work on notification=20 content (6 in room + 1 jabber in favour, no objections). The current charter does not cover this work and needs=20 to be extended. D1) Chairs will prepare charter text proposal and ask=20 the WG for comments and whether they are interested=20 doing work on network content. [Chairs] Cheers, Bert & Mehmet ------_=_NextPart_001_01C8FAD6.EE1C59C2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Summary of the NETCONF WG Session at IETF 72 and Action = Points

Dear NETCONF WG, =

after having sent = out the preliminary minutes we need
to confirm the = results of the NETCONF session. 

=3D> [Topic = owners] please start the necessary discussion
     or bring the action points = "[A-D]n)" to the maillist
     as soon as = possible.

Below is the = summary of the NETCONF WG session on
TUESDAY, July 29, = 2008 1850-1950.

- We had 35 persons = in the 1 hour NETCONF session.
- We reviewed the = stat0 a discussion and review of the documents. NETCONF Monitoring Schema (Mark Scott ) The NETCONF Monitoring needs some work before WGLC.=20 Issue #1: Which terminology should be used? schema or=20 model or data model ...? A1) The issue will be discussed on the maillist to try to=20 converge to consensus [Mark]. Issue #2: lack of agreed XSD definitions for data types=20 to use. The work on SMIv2-to-XSD translation in OPSAWG has=20 a different focus and does not solve the problem of=20 additional data types needed in NETCONF.=20 PS: There was additional disscussion on this issue in the=20 OPSAWG. The SMIv2-to-XSD document will be finalized=20 asap to see how it impacts YANG data type usage.=20 It has been proposed to define short-term data type=20 usage for NETCONF based on XSD. A2) The issue will be discussed first by the base=20 players Mark, Dave H, Bob Natale, J=FCrgen Sch=F6nw=E4lder=20 and co-chairs [Mark] A3) and will be brought to the maillist to reach a=20 consensus for the usage of data types in NETCONF [Mark]. Partial Lock RPC for NETCONF (Balazs Lengyel) Issue #1: Remove empty locks? Keep as it is. Issue #2: Does the granular locking put requirements on=20 other protocols that night lock the database? Keep the text in document. The document is ready for WG last call? 8 in favor,=20 no objections. B1) Update the document for clarifications [Balazs, done] B2) Bring the document to WGLC [Chairs] NETCONF over TLS (Mohamad Badra) Security AD Tim Polk does not see the additional value=20 in the document since the password-based SSH transport=20 is already mandatory. Tim Polk does not have any technical=20 objections to the use of TLS out of the box if the WG=20 decided so. The focus in the document should be on=20 certificate-based TLS. C1) Summarize the WG discussion and take the comments=20 of the security ADs Pasi Eronen and Tim Polk [Badra, mail sent]. C2) Bring AD comments to the maillist and ask for consensus=20 [Badra]. NETCONF Notification Content (Sharon Chisholm) The WG has interest of doing some work on notification=20 content (6 in room + 1 jabber in favour, no objections). The current charter does not cover this work and needs=20 to be extended. D1) Chairs will prepare charter text proposal and ask=20 the WG for comments and whether they are interested=20 doing work on network content. [Chairs] Cheers, Bert & Mehmet ------_=_NextPart_001_01C8FAD6.EE1C59C2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Summary of the NETCONF WG Session at IETF 72 and Action = Points

Dear NETCONF WG, =

after having sent = out the preliminary minutes we need
to confirm the = results of the NETCONF session. 

=3D> [Topic = owners] please start the necessary discussion
     or bring the action points = "[A-D]n)" to the maillist
     as soon as = possible.

Below is the = summary of the NETCONF WG session on
TUESDAY, July 29, = 2008 1850-1950.

- We had 35 persons = in the 1 hour NETCONF session.
- We reviewed the = status of us of the WG

- NETCONF = Notification draft has been published as
  RFC = 5277.
- We went through = the chartered WG items and had
  a = discussion and review of the documents.


NETCONF Monitoring = Schema (Mark Scott )

The NETCONF = Monitoring needs some work before WGLC.
Issue #1: Which = terminology should be used? schema or
model or data = model ...?

A1) The issue will = be discussed on the maillist to try to
converge to = consensus [Mark].

Issue #2: lack of = agreed XSD definitions for data types
to = use.
The work on = SMIv2-to-XSD translation in OPSAWG has
a different focus = and does not solve the problem of
additional data = types needed in NETCONF.

PS: There was = additional disscussion on this issue in the
OPSAWG. The = SMIv2-to-XSD document will be finalized
asap to see how it = impacts YANG data type usage.
It has been = proposed to define short-term data type
usage for NETCONF = based on XSD.

A2) The issue will = be discussed first by the base
players Mark, Dave = H, Bob Natale, J=FCrgen Sch=F6nw=E4lder
and co-chairs = [Mark]
A3) and will be = brought to the maillist to reach a
consensus for the = usage of data types in NETCONF [Mark].


Partial Lock RPC = for NETCONF (Balazs Lengyel)

Issue #1: Remove = empty locks?
Keep as it = is.
Issue #2: Does the = granular locking put requirements on
other protocols = that night lock the database?
Keep the text in = document.
The document is = ready for WG last call? 8 in favor,
no = objections.

B1) Update the = document for clarifications [Balazs, done]
B2) Bring the = document to WGLC [Chairs]


- NETCONF = Notification draft has been published as
  RFC = 5277.
- We went through = the chartered WG items and had
  a = discussion and review of the documents.


NETCONF Monitoring = Schema (Mark Scott )

The NETCONF = Monitoring needs some work before WGLC.
Issue #1: Which = terminology should be used? schema or
model or data = model ...?

A1) The issue will = be discussed on the maillist to try to
converge to = consensus [Mark].

Issue #2: lack of = agreed XSD definitions for data types
to = use.
The work on = SMIv2-to-XSD translation in OPSAWG has
a different focus = and does not solve the problem of
additional data = types needed in NETCONF.

PS: There was = additional disscussion on this issue in the
OPSAWG. The = SMIv2-to-XSD document will be finalized
asap to see how it = impacts YANG data type usage.
It has been = proposed to define short-term data type
usage for NETCONF = based on XSD.

A2) The issue will = be discussed first by the base
players Mark, Dave = H, Bob Natale, J=FCrgen Sch=F6nw=E4lder
and co-chairs = [Mark]
A3) and will be = brought to the maillist to reach a
consensus for the = usage of data types in NETCONF [Mark].


Partial Lock RPC = for NETCONF (Balazs Lengyel)

Issue #1: Remove = empty locks?
Keep as it = is.
Issue #2: Does the = granular locking put requirements on
other protocols = that night lock the database?
Keep the text in = document.
The document is = ready for WG last call? 8 in favor,
no = objections.

B1) Update the = document for clarifications [Balazs, done]
B2) Bring the = document to WGLC [Chairs]


NETCONF over TLS = (Mohamad Badra)

Security AD Tim = Polk does not see the additional value
in the document = since the password-based SSH transport
is already = mandatory. Tim Polk does not have any technical
objections to the = use of TLS out of the box if the WG
decided so. The = focus in the document should be on
certificate-based = TLS.

C1) Summarize the = WG discussion and take the comments
of the security = ADs Pasi Eronen and Tim Polk [Badra, mail sent].
C2) Bring AD = comments to the maillist and ask for consensus
[Badra].


NETCONF = Notification Content (Sharon Chisholm)

The WG has interest = of doing some work on notification
content (6 in room = + 1 jabber in favour, no objections).
The current = charter does not cover this work and needs
to be = extended.

D1) Chairs will = prepare charter text proposal and ask
the WG for = comments and whether they are interested
doing work on = network content. [Chairs]


Cheers,
Bert & = Mehmet

------_=_NextPart_001_01C8FAD6.EE1C59C2-- --===============0251020713== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0251020713==-- G=3D"de">NETCONF over TLS = (Mohamad Badra)

Security AD Tim = Polk does not see the additional value
in the document = since the password-based SSH transport
is already = mandatory. Tim Polk does not have any technical
objections to the = use of TLS out of the box if the WG
decided so. The = focus in the document should be on
certificate-based = TLS.

C1) Summarize the = WG discussion and take the comments
of the security = ADs Pasi Eronen and Tim Polk [Badra, mail sent].
C2) Bring AD = comments to the maillist and ask for consensus
[Badra].


NETCONF = Notification Content (Sharon Chisholm)

The WG has interest = of doing some work on notification
content (6 in room = + 1 jabber in favour, no objections).
The current = charter does not cover this work and needs
to be = extended.

D1) Chairs will = prepare charter text proposal and ask
the WG for = comments and whether they are interested
doing work on = network content. [Chairs]


Cheers,
Bert & = Mehmet

------_=_NextPart_001_01C8FAD6.EE1C59C2-- --===============0251020713== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0251020713==-- From netconf-bounces@ietf.org Sun Aug 10 04:30:50 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C56CD28C17D; Sun, 10 Aug 2008 04:30:50 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6370428C17D for ; Sun, 10 Aug 2008 04:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.948 X-Spam-Level: X-Spam-Status: No, score=-4.948 tagged_above=-999 required=5 tests=[AWL=1.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZHNsPPf6hgM for ; Sun, 10 Aug 2008 04:30:48 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 45EBD28C17B for ; Sun, 10 Aug 2008 04:30:48 -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 m7ABUlmC024823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Aug 2008 13:30:48 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m7ABUlMH014688; Sun, 10 Aug 2008 13:30:47 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 10 Aug 2008 13:30:48 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 10 Aug 2008 13:30:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for draft-ietf-netconf-partial-lock-03.txt Thread-Index: Acj63IbbqOH4DorZRMmxmi33pAZLqw== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 10 Aug 2008 11:30:48.0148 (UTC) FILETIME=[8930B940:01C8FADC] Subject: [Netconf] WGLC for draft-ietf-netconf-partial-lock-03.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: , Content-Type: multipart/mixed; boundary="===============1515886319==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1515886319== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8FADC.878E72EC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8FADC.878E72EC Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All, as discussed in the NETCONF session Balazs updated=20 the draft "Partial Lock RPC for NETCONF" (see http://tools.ietf.org/html/draft-ietf-netconf-partial-lock-03). The draft has been discussed in this group and appears=20 to be stable for WGLC. With this mail we start a WGLC for the Partial Lock=20 draft, which is proposed to publish as a Proposed=20 Standard RFC. =20 The WGLC starts on August 10, 2008 and will run for=20 two weeks until August 24, 2008. Everybody on the NETCONF WG please review the=20 draft again and send your comments to the NETCONF=20 maillist. Thank you and looking forward for your reviews and=20 comments. Cheers,=20 Mehmet ------_=_NextPart_001_01C8FADC.878E72EC Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable WGLC for draft-ietf-netconf-partial-lock-03.txt

Hi = All,

as discussed in the = NETCONF session Balazs updated
the draft = "Partial Lock RPC for NETCONF" (see
http://tools.ietf.org/html/draft-ietf-netconf-partial-lo= ck-03).
The draft has = been discussed in this group and appears
to be stable = for WGLC.

With this mail = we start a WGLC for the Partial Lock
draft, which is = proposed to publish as a Proposed
Standard = RFC.
 
The WGLC starts = on August 10, 2008 and will run for
two weeks until = August 24, 2008.

Everybody on the = NETCONF WG please review the
draft again and = send your comments to the NETCONF
maillist.

Thank you and = looking forward for your reviews and
comments.

Cheers,
Mehmet

------_=_NextPart_001_01C8FADC.878E72EC-- --===============1515886319== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1515886319==-- From netconf-bounces@ietf.org Sun Aug 10 04:30:50 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C56CD28C17D; Sun, 10 Aug 2008 04:30:50 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6370428C17D for ; Sun, 10 Aug 2008 04:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.948 X-Spam-Level: X-Spam-Status: No, score=-4.948 tagged_above=-999 required=5 tests=[AWL=1.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZHNsPPf6hgM for ; Sun, 10 Aug 2008 04:30:48 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 45EBD28C17B for ; Sun, 10 Aug 2008 04:30:48 -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 m7ABUlmC024823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Aug 2008 13:30:48 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m7ABUlMH014688; Sun, 10 Aug 2008 13:30:47 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 10 Aug 2008 13:30:48 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 10 Aug 2008 13:30:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for draft-ietf-netconf-partial-lock-03.txt Thread-Index: Acj63IbbqOH4DorZRMmxmi33pAZLqw== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 10 Aug 2008 11:30:48.0148 (UTC) FILETIME=[8930B940:01C8FADC] Subject: [Netconf] WGLC for draft-ietf-netconf-partial-lock-03.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: , Content-Type: multipart/mixed; boundary="===============1515886319==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1515886319== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8FADC.878E72EC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8FADC.878E72EC Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All, as discussed in the NETCONF session Balazs updated=20 the draft "Partial Lock RPC for NETCONF" (see http://tools.ietf.org/html/draft-ietf-netconf-partial-lock-03). The draft has been discussed in this group and appears=20 to be stable for WGLC. With this mail we start a WGLC for the Partial Lock=20 draft, which is proposed to publish as a Proposed=20 Standard RFC. =20 The WGLC starts on August 10, 2008 and will run for=20 two weeks until August 24, 2008. Everybody on the NETCONF WG please review the=20 draft again and send your comments to the NETCONF=20 maillist. Thank you and looking forward for your reviews and=20 comments. Cheers,=20 Mehmet ------_=_NextPart_001_01C8FADC.878E72EC Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable WGLC for draft-ietf-netconf-partial-lock-03.txt

Hi = All,

as discussed in the = NETCONF session Balazs updated
the draft = "Partial Lock RPC for NETCONF" (see
http://tools.ietf.org/html/draft-ietf-netconf-partial-lo= ck-03).
The draft has = been discussed in this group and appears
to be stable = for WGLC.

With this mail = we start a WGLC for the Partial Lock
draft, which is = proposed to publish as a Proposed
Standard = RFC.
 
The WGLC starts = on August 10, 2008 and will run for
two weeks until = August 24, 2008.

Everybody on the = NETCONF WG please review the
draft again and = send your comments to the NETCONF
maillist.

Thank you and = looking forward for your reviews and
comments.

Cheers,
Mehmet

------_=_NextPart_001_01C8FADC.878E72EC-- --===============1515886319== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1515886319==-- From netconf-bounces@ietf.org Mon Aug 11 03:57:29 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17E793A6D03; Mon, 11 Aug 2008 03:57:29 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C205E3A6D03 for ; Mon, 11 Aug 2008 03:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.344 X-Spam-Level: X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[AWL=-0.210, 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 dAbGVQOIhCWo for ; Mon, 11 Aug 2008 03:57:28 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0D5293A69F2 for ; Mon, 11 Aug 2008 03:57:27 -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 C640F76C4D6 for ; Mon, 11 Aug 2008 12:56:47 +0200 (CEST) Date: Mon, 11 Aug 2008 12:56:39 +0200 (CEST) Message-Id: <20080811.125639.113447801.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Subject: [Netconf] rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Section 4.2 of rfc4741 says: The response name and response data are encoded as the contents of the element. The name of the reply is an element directly inside the element, and any data is encoded inside this element. Note "the name of the reply is an element...". Is the intention that each rpc operation can define its own reply element? Always exactly one element? This is not reflected in the XSD. The XSD allows one or ... element only. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Aug 11 03:57:29 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17E793A6D03; Mon, 11 Aug 2008 03:57:29 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C205E3A6D03 for ; Mon, 11 Aug 2008 03:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.344 X-Spam-Level: X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[AWL=-0.210, 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 dAbGVQOIhCWo for ; Mon, 11 Aug 2008 03:57:28 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0D5293A69F2 for ; Mon, 11 Aug 2008 03:57:27 -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 C640F76C4D6 for ; Mon, 11 Aug 2008 12:56:47 +0200 (CEST) Date: Mon, 11 Aug 2008 12:56:39 +0200 (CEST) Message-Id: <20080811.125639.113447801.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Subject: [Netconf] rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Section 4.2 of rfc4741 says: The response name and response data are encoded as the contents of the element. The name of the reply is an element directly inside the element, and any data is encoded inside this element. Note "the name of the reply is an element...". Is the intention that each rpc operation can define its own reply element? Always exactly one element? This is not reflected in the XSD. The XSD allows one or ... element only. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Aug 11 06:32:18 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C90963A6824; Mon, 11 Aug 2008 06:32:18 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9041B3A6824 for ; Mon, 11 Aug 2008 06:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 HBideAWVEPi9 for ; Mon, 11 Aug 2008 06:32:16 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id 32BF53A67B5 for ; Mon, 11 Aug 2008 06:32:15 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Mon, 11 Aug 2008 06:31:54 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 06:31:39 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 06:31:38 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Aug 2008 06:30: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 m7BDUqu29423; Mon, 11 Aug 2008 06:30:52 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7BDRXPo097311; Mon, 11 Aug 2008 13:27:34 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808111327.m7BDRXPo097311@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080811.125639.113447801.mbj@tail-f.com> Date: Mon, 11 Aug 2008 09:27:33 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Aug 2008 13:30:53.0262 (UTC) FILETIME=[7A2F9EE0:01C8FBB6] Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund writes: >Note "the name of the reply is an element...". Is the intention that >each rpc operation can define its own reply element? Always exactly >one element? This is not reflected in the XSD. The XSD allows one > or ... element only. IMHO this is a bug in the XSD and we are allowed to return content directly inside the , but Andy's take is that it's a bug in the text and all returned data should always be in the element. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Aug 11 06:32:18 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C90963A6824; Mon, 11 Aug 2008 06:32:18 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9041B3A6824 for ; Mon, 11 Aug 2008 06:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 HBideAWVEPi9 for ; Mon, 11 Aug 2008 06:32:16 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id 32BF53A67B5 for ; Mon, 11 Aug 2008 06:32:15 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Mon, 11 Aug 2008 06:31:54 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 06:31:39 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 06:31:38 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Aug 2008 06:30: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 m7BDUqu29423; Mon, 11 Aug 2008 06:30:52 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7BDRXPo097311; Mon, 11 Aug 2008 13:27:34 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808111327.m7BDRXPo097311@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080811.125639.113447801.mbj@tail-f.com> Date: Mon, 11 Aug 2008 09:27:33 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Aug 2008 13:30:53.0262 (UTC) FILETIME=[7A2F9EE0:01C8FBB6] Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund writes: >Note "the name of the reply is an element...". Is the intention that >each rpc operation can define its own reply element? Always exactly >one element? This is not reflected in the XSD. The XSD allows one > or ... element only. IMHO this is a bug in the XSD and we are allowed to return content directly inside the , but Andy's take is that it's a bug in the text and all returned data should always be in the element. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Aug 11 07:30:20 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8393A6D69; Mon, 11 Aug 2008 07:30:20 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 580103A6D6E for ; Mon, 11 Aug 2008 07:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.411, 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 9XvWh9wHTsqm for ; Mon, 11 Aug 2008 07:30:18 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id AB4B63A6D4E for ; Mon, 11 Aug 2008 07:30:18 -0700 (PDT) Received: (qmail 78217 invoked from network); 11 Aug 2008 14:30:15 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 11 Aug 2008 14:30:14 -0000 X-YMail-OSG: MvrixUsVM1nMx.Fn4AHri7wWhJyA1UyTD8FtMNFquwffqa7gLjK2HsMNkC86JKWDrWge2xrCE98dOaacCMiziM8Z9GPmvpkUylGYX93Bzg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A04CF4.9000102@netconfcentral.com> Date: Mon, 11 Aug 2008 07:30:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808111327.m7BDRXPo097311@idle.juniper.net> In-Reply-To: <200808111327.m7BDRXPo097311@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Martin Bjorklund writes: >> Note "the name of the reply is an element...". Is the intention that >> each rpc operation can define its own reply element? Always exactly >> one element? This is not reflected in the XSD. The XSD allows one >> or ... element only. > No -- there is only one standard element and it also allows * instead of ?. > IMHO this is a bug in the XSD and we are allowed to return content > directly inside the , but Andy's take is that it's a bug > in the text and all returned data should always be in the > element. > Yes -- the WG wanted to include the element in the replies that returned more than status. It provides a consistent way to determine that 'the empty set' was returned (e.g., filter did not match anything.) > Thanks, > Phil > ________ Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Aug 11 07:30:20 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8393A6D69; Mon, 11 Aug 2008 07:30:20 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 580103A6D6E for ; Mon, 11 Aug 2008 07:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.411, 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 9XvWh9wHTsqm for ; Mon, 11 Aug 2008 07:30:18 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id AB4B63A6D4E for ; Mon, 11 Aug 2008 07:30:18 -0700 (PDT) Received: (qmail 78217 invoked from network); 11 Aug 2008 14:30:15 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 11 Aug 2008 14:30:14 -0000 X-YMail-OSG: MvrixUsVM1nMx.Fn4AHri7wWhJyA1UyTD8FtMNFquwffqa7gLjK2HsMNkC86JKWDrWge2xrCE98dOaacCMiziM8Z9GPmvpkUylGYX93Bzg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A04CF4.9000102@netconfcentral.com> Date: Mon, 11 Aug 2008 07:30:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808111327.m7BDRXPo097311@idle.juniper.net> In-Reply-To: <200808111327.m7BDRXPo097311@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Martin Bjorklund writes: >> Note "the name of the reply is an element...". Is the intention that >> each rpc operation can define its own reply element? Always exactly >> one element? This is not reflected in the XSD. The XSD allows one >> or ... element only. > No -- there is only one standard element and it also allows * instead of ?. > IMHO this is a bug in the XSD and we are allowed to return content > directly inside the , but Andy's take is that it's a bug > in the text and all returned data should always be in the > element. > Yes -- the WG wanted to include the element in the replies that returned more than status. It provides a consistent way to determine that 'the empty set' was returned (e.g., filter did not match anything.) > Thanks, > Phil > ________ Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Aug 11 07:59:43 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71B6A3A6BEC; Mon, 11 Aug 2008 07:59:43 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1A083A69AF for ; Mon, 11 Aug 2008 07:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 cgotHsERoXB1 for ; Mon, 11 Aug 2008 07:59:41 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id 2E2A83A6BEC for ; Mon, 11 Aug 2008 07:59:39 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Mon, 11 Aug 2008 07:58:43 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 07:59:05 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 07:59:04 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 07:59: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 m7BEx3u54066; Mon, 11 Aug 2008 07:59:03 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7BEtj4X098408; Mon, 11 Aug 2008 14:55:45 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808111455.m7BEtj4X098408@idle.juniper.net> To: Andy Bierman In-reply-to: <48A04CF4.9000102@netconfcentral.com> Date: Mon, 11 Aug 2008 10:55:44 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Aug 2008 14:59:04.0345 (UTC) FILETIME=[CBEAD090:01C8FBC2] Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >Yes -- the WG wanted to include the element in >the replies that returned more than status. Last time this issue came up, I looked for this discussion to see how the concensus was found and couldn't find it. Could you point me to it? >It provides >a consistent way to determine that 'the empty set' was >returned (e.g., filter did not match anything.) This is for , which is the one place the element is referenced in the text. 7.1. ... Positive Response: If the device can satisfy the request, the server sends an element containing a element with the results of the query. This is not true for other RPCs. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Aug 11 07:59:43 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71B6A3A6BEC; Mon, 11 Aug 2008 07:59:43 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1A083A69AF for ; Mon, 11 Aug 2008 07:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 cgotHsERoXB1 for ; Mon, 11 Aug 2008 07:59:41 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id 2E2A83A6BEC for ; Mon, 11 Aug 2008 07:59:39 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Mon, 11 Aug 2008 07:58:43 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 07:59:05 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 07:59:04 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 07:59: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 m7BEx3u54066; Mon, 11 Aug 2008 07:59:03 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7BEtj4X098408; Mon, 11 Aug 2008 14:55:45 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808111455.m7BEtj4X098408@idle.juniper.net> To: Andy Bierman In-reply-to: <48A04CF4.9000102@netconfcentral.com> Date: Mon, 11 Aug 2008 10:55:44 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Aug 2008 14:59:04.0345 (UTC) FILETIME=[CBEAD090:01C8FBC2] Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >Yes -- the WG wanted to include the element in >the replies that returned more than status. Last time this issue came up, I looked for this discussion to see how the concensus was found and couldn't find it. Could you point me to it? >It provides >a consistent way to determine that 'the empty set' was >returned (e.g., filter did not match anything.) This is for , which is the one place the element is referenced in the text. 7.1. ... Positive Response: If the device can satisfy the request, the server sends an element containing a element with the results of the query. This is not true for other RPCs. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Aug 11 08:12:35 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1D33A6E48; Mon, 11 Aug 2008 08:12:35 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2FE63A6DD7 for ; Mon, 11 Aug 2008 08:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=0.396, 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 sFAex4w9108Q for ; Mon, 11 Aug 2008 08:12:34 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id B900A3A6CB8 for ; Mon, 11 Aug 2008 08:11:47 -0700 (PDT) Received: (qmail 88154 invoked from network); 11 Aug 2008 15:11:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 11 Aug 2008 15:11:48 -0000 X-YMail-OSG: WLAiZ1kVM1nvV6krSXiwfCrNa.jsM1cDmf5kYmeD5T1QNHJgAnwYz_JiJCx43J.X5mQvHzEB7B.Td5FPgcxm9lf8CM6hCJz6XAeB31XVkw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A056B3.7090907@netconfcentral.com> Date: Mon, 11 Aug 2008 08:11:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808111455.m7BEtj4X098408@idle.juniper.net> In-Reply-To: <200808111455.m7BEtj4X098408@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> Yes -- the WG wanted to include the element in >> the replies that returned more than status. > > Last time this issue came up, I looked for this discussion to see > how the concensus was found and couldn't find it. Could you point > me to it? > >> It provides >> a consistent way to determine that 'the empty set' was >> returned (e.g., filter did not match anything.) > > This is for , which is the one place the > element is referenced in the text. > > 7.1. > ... > Positive Response: > > If the device can satisfy the request, the server sends an > element containing a element with the results > of the query. > > This is not true for other RPCs. > It is for the ones that return data: get and get-config. No other operations actually return data in the response. All other standard operations return or . > Thanks, > Phil > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Aug 11 08:12:35 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1D33A6E48; Mon, 11 Aug 2008 08:12:35 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2FE63A6DD7 for ; Mon, 11 Aug 2008 08:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=0.396, 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 sFAex4w9108Q for ; Mon, 11 Aug 2008 08:12:34 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id B900A3A6CB8 for ; Mon, 11 Aug 2008 08:11:47 -0700 (PDT) Received: (qmail 88154 invoked from network); 11 Aug 2008 15:11:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 11 Aug 2008 15:11:48 -0000 X-YMail-OSG: WLAiZ1kVM1nvV6krSXiwfCrNa.jsM1cDmf5kYmeD5T1QNHJgAnwYz_JiJCx43J.X5mQvHzEB7B.Td5FPgcxm9lf8CM6hCJz6XAeB31XVkw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A056B3.7090907@netconfcentral.com> Date: Mon, 11 Aug 2008 08:11:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808111455.m7BEtj4X098408@idle.juniper.net> In-Reply-To: <200808111455.m7BEtj4X098408@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> Yes -- the WG wanted to include the element in >> the replies that returned more than status. > > Last time this issue came up, I looked for this discussion to see > how the concensus was found and couldn't find it. Could you point > me to it? > >> It provides >> a consistent way to determine that 'the empty set' was >> returned (e.g., filter did not match anything.) > > This is for , which is the one place the > element is referenced in the text. > > 7.1. > ... > Positive Response: > > If the device can satisfy the request, the server sends an > element containing a element with the results > of the query. > > This is not true for other RPCs. > It is for the ones that return data: get and get-config. No other operations actually return data in the response. All other standard operations return or . > Thanks, > Phil > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Aug 11 08:42:34 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E483728C0E9; Mon, 11 Aug 2008 08:42:34 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCCC83A6D45 for ; Mon, 11 Aug 2008 08:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEswT03diA+2 for ; Mon, 11 Aug 2008 08:42:28 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id AB4C23A6E85 for ; Mon, 11 Aug 2008 08:42:26 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Mon, 11 Aug 2008 08:41:52 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 08:41:41 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 08:41:40 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 08:40:47 -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 m7BFeku66821; Mon, 11 Aug 2008 08:40:46 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7BFbSS2098789; Mon, 11 Aug 2008 15:37:28 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808111537.m7BFbSS2098789@idle.juniper.net> To: Andy Bierman In-reply-to: <48A056B3.7090907@netconfcentral.com> Date: Mon, 11 Aug 2008 11:37:28 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Aug 2008 15:40:47.0421 (UTC) FILETIME=[9FDDE6D0:01C8FBC8] Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >It is for the ones that return data: get and get-config. >No other operations actually return data in the response. We're discussing the generic RPC definitions in 4.2, not the specific RPCs like get and get-config which specifically define their own content. 4.2 says: The response name and response data are encoded as the contents of the element. The name of the reply is an element directly inside the element, and any data is encoded inside this element. which means one can define an RPC called that returns as an element directly inside the . 10.1.2.3 10.1.2.3 10.1.2.3 56 5 0 100 no response The question is whether this requires an argument to "output": rpc ping { input { leaf host { ... } } output ping-results { leaf target-host { ... } leaf target-op { ... } leaf packet-size { ... } ... } } or: rpc ping { input { leaf host { ... } } output { container ping-results { leaf target-host { ... } leaf target-op { ... } leaf packet-size { ... } ... } } } I'm using the latter now, but moving to the former is fine with me. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Aug 11 08:42:35 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E483728C0E9; Mon, 11 Aug 2008 08:42:34 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCCC83A6D45 for ; Mon, 11 Aug 2008 08:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEswT03diA+2 for ; Mon, 11 Aug 2008 08:42:28 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id AB4C23A6E85 for ; Mon, 11 Aug 2008 08:42:26 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Mon, 11 Aug 2008 08:41:52 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 08:41:41 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 08:41:40 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 08:40:47 -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 m7BFeku66821; Mon, 11 Aug 2008 08:40:46 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7BFbSS2098789; Mon, 11 Aug 2008 15:37:28 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808111537.m7BFbSS2098789@idle.juniper.net> To: Andy Bierman In-reply-to: <48A056B3.7090907@netconfcentral.com> Date: Mon, 11 Aug 2008 11:37:28 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Aug 2008 15:40:47.0421 (UTC) FILETIME=[9FDDE6D0:01C8FBC8] Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >It is for the ones that return data: get and get-config. >No other operations actually return data in the response. We're discussing the generic RPC definitions in 4.2, not the specific RPCs like get and get-config which specifically define their own content. 4.2 says: The response name and response data are encoded as the contents of the element. The name of the reply is an element directly inside the element, and any data is encoded inside this element. which means one can define an RPC called that returns as an element directly inside the . 10.1.2.3 10.1.2.3 10.1.2.3 56 5 0 100 no response The question is whether this requires an argument to "output": rpc ping { input { leaf host { ... } } output ping-results { leaf target-host { ... } leaf target-op { ... } leaf packet-size { ... } ... } } or: rpc ping { input { leaf host { ... } } output { container ping-results { leaf target-host { ... } leaf target-op { ... } leaf packet-size { ... } ... } } } I'm using the latter now, but moving to the former is fine with me. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Aug 11 08:54:24 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2E843A69A5; Mon, 11 Aug 2008 08:54:23 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7BD3A6358 for ; Mon, 11 Aug 2008 08:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.383, 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 m68A9ED2Wn-d for ; Mon, 11 Aug 2008 08:54:20 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 9B0423A67E2 for ; Mon, 11 Aug 2008 08:54:20 -0700 (PDT) Received: (qmail 67695 invoked from network); 11 Aug 2008 15:54:23 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 11 Aug 2008 15:54:21 -0000 X-YMail-OSG: F7WnMvAVM1lFe7TrzzYug4T.gbS508.gV2chibuiT5Fe5L_qs.CoQpXqD9mtuydscZUvYojMH.f7dLkth_My094j.ZzOUJ5SPa4GwEOvpQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A060AC.70203@netconfcentral.com> Date: Mon, 11 Aug 2008 08:54:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808111537.m7BFbSS2098789@idle.juniper.net> In-Reply-To: <200808111537.m7BFbSS2098789@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> It is for the ones that return data: get and get-config. >> No other operations actually return data in the response. > > We're discussing the generic RPC definitions in 4.2, not the specific > RPCs like get and get-config which specifically define their own > content. > > 4.2 says: > > The response name and response data are encoded as the contents of > the element. The name of the reply is an element > directly inside the element, and any data is encoded > inside this element. > > which means one can define an RPC called that returns > as an element directly inside the . > > > > 10.1.2.3 > > > > > 10.1.2.3 > 10.1.2.3 > 56 > > 5 > 0 > 100 > > no response > > > > The question is whether this requires an argument to "output": > > > rpc ping { > input { > leaf host { ... } > } > outputFrom netconf-bounces@ietf.org Mon Aug 11 08:54:24 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2E843A69A5; Mon, 11 Aug 2008 08:54:23 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7BD3A6358 for ; Mon, 11 Aug 2008 08:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.383, 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 m68A9ED2Wn-d for ; Mon, 11 Aug 2008 08:54:20 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 9B0423A67E2 for ; Mon, 11 Aug 2008 08:54:20 -0700 (PDT) Received: (qmail 67695 invoked from network); 11 Aug 2008 15:54:23 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.105.251 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 11 Aug 2008 15:54:21 -0000 X-YMail-OSG: F7WnMvAVM1lFe7TrzzYug4T.gbS508.gV2chibuiT5Fe5L_qs.CoQpXqD9mtuydscZUvYojMH.f7dLkth_My094j.ZzOUJ5SPa4GwEOvpQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A060AC.70203@netconfcentral.com> Date: Mon, 11 Aug 2008 08:54:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808111537.m7BFbSS2098789@idle.juniper.net> In-Reply-To: <200808111537.m7BFbSS2098789@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> It is for the ones that return data: get and get-config. >> No other operations actually return data in the response. > > We're discussing the generic RPC definitions in 4.2, not the specific > RPCs like get and get-config which specifically define their own > content. > > 4.2 says: > > The response name and response data are encoded as the contents of > the element. The name of the reply is an element > directly inside the element, and any data is encoded > inside this element. > > which means one can define an RPC called that returns > as an element directly inside the . > > > > 10.1.2.3 > > > > > 10.1.2.3 > 10.1.2.3 > 56 > > 5 > 0 > 100 > > no response > > > > The question is whether this requires an argument to "output": > > > rpc ping { > input { > leaf host { ... } > } > ping-results { > leaf target-host { ... } > leaf target-op { ... } > leaf packet-size { ... } > ... > } > } > > or: > > rpc ping { > input { > leaf host { ... } > } > output { > container ping-results { > leaf target-host { ... } > leaf target-op { ... } > leaf packet-size { ... } > ... > } > } > } > > I'm using the latter now, but moving to the former is fine with me. > I see your point. No problem. I prefer the latter solution because changing the output statement has an impact on the augment statement. It is also more intuitive to think of both 'input' and 'output' as conceptual containers that do not really exist in the PDU XML. Also, the current design allows multiple elements (via augments) to be included in the output. Changing output-stmt would prevent the addition of sibling nodes to 'ping-results'. > Thanks, > Phil Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf output ping-results { > leaf target-host { ... } > leaf target-op { ... } > leaf packet-size { ... } > ... > } > } > > or: > > rpc ping { > input { > leaf host { ... } > } > output { > container ping-results { > leaf target-host { ... } > leaf target-op { ... } > leaf packet-size { ... } > ... > } > } > } > > I'm using the latter now, but moving to the former is fine with me. > I see your point. No problem. I prefer the latter solution because changing the output statement has an impact on the augment statement. It is also more intuitive to think of both 'input' and 'output' as conceptual containers that do not really exist in the PDU XML. Also, the current design allows multiple elements (via augments) to be included in the output. Changing output-stmt would prevent the addition of sibling nodes to 'ping-results'. > Thanks, > Phil Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Aug 11 11:32:40 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4793A69CA; Mon, 11 Aug 2008 11:32:40 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB4053A69CA for ; Mon, 11 Aug 2008 11:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 qE5tZOyqpHMm for ; Mon, 11 Aug 2008 11:32: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 3CF393A6801 for ; Mon, 11 Aug 2008 11:32:38 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 9930076C4D6; Mon, 11 Aug 2008 20:32:20 +0200 (CEST) Date: Mon, 11 Aug 2008 20:32:57 +0200 (CEST) Message-Id: <20080811.203257.128375678.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48A060AC.70203@netconfcentral.com> References: <200808111537.m7BFbSS2098789@idle.juniper.net> <48A060AC.70203@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I asked this question to the netconf WG but it of course impacts what will be done in netmod. Going back to my original question: Section 4.2 of rfc4741 says: The response name and response data are encoded as the contents of the element. The name of the reply is an element directly inside the element, and any data is encoded inside this element. Does the WG think that this text is correct, and the XSD wrong? If so, should I interpret "the reply is an element" as saying that there can be *one* reply and never more? For example, is this illegal: 10.1.2.3 10.1.2.3 10.1.2.3 56 5 0 100 no response /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Aug 11 11:32:40 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4793A69CA; Mon, 11 Aug 2008 11:32:40 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB4053A69CA for ; Mon, 11 Aug 2008 11:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 qE5tZOyqpHMm for ; Mon, 11 Aug 2008 11:32: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 3CF393A6801 for ; Mon, 11 Aug 2008 11:32:38 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 9930076C4D6; Mon, 11 Aug 2008 20:32:20 +0200 (CEST) Date: Mon, 11 Aug 2008 20:32:57 +0200 (CEST) Message-Id: <20080811.203257.128375678.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48A060AC.70203@netconfcentral.com> References: <200808111537.m7BFbSS2098789@idle.juniper.net> <48A060AC.70203@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I asked this question to the netconf WG but it of course impacts what will be done in netmod. Going back to my original question: Section 4.2 of rfc4741 says: The response name and response data are encoded as the contents of the element. The name of the reply is an element directly inside the element, and any data is encoded inside this element. Does the WG think that this text is correct, and the XSD wrong? If so, should I interpret "the reply is an element" as saying that there can be *one* reply and never more? For example, is this illegal: 10.1.2.3 10.1.2.3 10.1.2.3 56 5 0 100 no response /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Aug 18 14:48:44 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5EE3A6C21; Mon, 18 Aug 2008 14:48:42 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 437163A68E1 for ; Mon, 18 Aug 2008 14:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.084 X-Spam-Level: X-Spam-Status: No, score=-1.084 tagged_above=-999 required=5 tests=[AWL=-1.086, BAYES_50=0.001, 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 Vc7favyhtqaA for ; Mon, 18 Aug 2008 14:48:36 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id E06C23A6BE9 for ; Mon, 18 Aug 2008 14:48:35 -0700 (PDT) Received: (qmail 79171 invoked from network); 18 Aug 2008 21:48:15 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 18 Aug 2008 21:48:15 -0000 Message-ID: From: "Bert Wijnen \(IETF\)" To: References: In-Reply-To: Date: Mon, 18 Aug 2008 23:47:40 +0200 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: [Netconf] Reminder, Action Points [was: Summary of the NETCONF WG Session at IETF 72 and Action Points] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org In the IETF72 WG meeting summary (attached below), we have pointed out several action points. We'd like to remind everyone to please execute on those action points, so that we make progress to a converged resolution and to completed documents. We have seen some initial action, but we need to see more! The action points were/are: A) Monitoring Draft [Mark] A1) Monitoring daft [Mark Scott] Which terminology should be used? schema or model or data model ...? The issue will be discussed on the maillist to try to converge to consensus. A2) Monitoring Draft [Mark Scott] No agreed XSD definitions for data types to use. The work on SMIv2-to-XSD translation in OPSAWG has a different focus and does not solve the problem of additional data types needed in NETCONF. The issue will be discussed first by the base players Mark, Dave H, Bob Natale, J=FCrgen Sch=F6nw=E4lder and co-chairs. A3) Monitoring Draft [Mark Scott] Issue A2 will then be brought to the maillist to reach a consensus for the usage of data types in NETCONF. B Partial Locking Draft [Balazs] B1) Remove empty locks? Keep as it is. Update the document for clarifications [Balazs, done] B2) The document is ready for WG last call? 8 in favor, no objectionsFrom netconf-bounces@ietf.org Mon Aug 18 14:48:44 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5EE3A6C21; Mon, 18 Aug 2008 14:48:42 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 437163A68E1 for ; Mon, 18 Aug 2008 14:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.084 X-Spam-Level: X-Spam-Status: No, score=-1.084 tagged_above=-999 required=5 tests=[AWL=-1.086, BAYES_50=0.001, 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 Vc7favyhtqaA for ; Mon, 18 Aug 2008 14:48:36 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id E06C23A6BE9 for ; Mon, 18 Aug 2008 14:48:35 -0700 (PDT) Received: (qmail 79171 invoked from network); 18 Aug 2008 21:48:15 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 18 Aug 2008 21:48:15 -0000 Message-ID: From: "Bert Wijnen \(IETF\)" To: References: In-Reply-To: Date: Mon, 18 Aug 2008 23:47:40 +0200 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: [Netconf] Reminder, Action Points [was: Summary of the NETCONF WG Session at IETF 72 and Action Points] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org In the IETF72 WG meeting summary (attached below), we have pointed out several action points. We'd like to remind everyone to please execute on those action points, so that we make progress to a converged resolution and to completed documents. We have seen some initial action, but we need to see more! The action points were/are: A) Monitoring Draft [Mark] A1) Monitoring daft [Mark Scott] Which terminology should be used? schema or model or data model ...? The issue will be discussed on the maillist to try to converge to consensus. A2) Monitoring Draft [Mark Scott] No agreed XSD definitions for data types to use. The work on SMIv2-to-XSD translation in OPSAWG has a different focus and does not solve the problem of additional data types needed in NETCONF. The issue will be discussed first by the base players Mark, Dave H, Bob Natale, J=FCrgen Sch=F6nw=E4lder and co-chairs. A3) Monitoring Draft [Mark Scott] Issue A2 will then be brought to the maillist to reach a consensus for the usage of data types in NETCONF. B Partial Locking Draft [Balazs] B1) Remove empty locks? Keep as it is. Update the document for clarifications [Balazs, done] B2) The document is ready for WG last call? 8 in favor, no objections. Bring the document to WGLC [Chairs, done] WG Last Call is running from Aug 10 till Aug24 [All WG members] PLEASE, all WG members should review and post their comments (also a "I have read it and am happy with it" is useful information). C) NETCONF over TLS (Mohamad Badra) C1) Need to focus on out-of-box usafge of TLS. Summarize the WG discussion and take the comments of the security ADs Pasi Eronen and Tim Polk [Badra, mail sent, follow still needs to happen.] C2) Bring (security) AD comments to the maillist and drive for consensus [Badra]. D) NETCONF Notification Content (Sharon Chisholm) The WG has interest of doing some work on notification content (6 in room + 1 jabber in favour, no objections). The current charter does not cover this work and needs to be extended. D1) Chairs will prepare charter text proposal and ask the WG for comments and whether they are interested doing work on network content. [Chairs] Bert and Mehmet ----- Original Message ----- = From: "Ersue, Mehmet (NSN - DE/Munich)" To: Cc: "ext Bert Wijnen (IETF)" Sent: Sunday, August 10, 2008 12:50 PM Subject: Summary of the NETCONF WG Session at IETF 72 and Action Points Dear NETCONF WG, after having sent out the preliminary minutes we need to confirm the results of the NETCONF session. =3D> [Topic owners] please start the necessary discussion or bring the action points "[A-D]n)" to the maillist as soon as possible. Below is the summary of the NETCONF WG session on TUESDAY, July 29, 2008 1850-1950. - We had 35 persons in the 1 hour NETCONF session. - We reviewed the status of the WG - NETCONF Notification draft has been published as RFC 5277. - We went through the chartered WG items and had a discussion and review of the documents. NETCONF Monitoring Schema (Mark Scott ) The NETCONF Monitoring needs some work before WGLC. Issue #1: Which terminology should be used? schema or model or data model ...? A1) The issue will be discussed on the maillist to try to converge to consensus [Mark]. Issue #2: lack of agreed XSD definitions for data types to use. The work on SMIv2-to-XSD translation in OPSAWG has a different focus and does not solve the problem of additional data types needed in NETCONF. PS: There was additional disscussion on this issue in the OPSAWG. The SMIv2-to-XSD document will be finalized asap to see how it impacts YANG data type usage. It has been proposed to define short-term data type usage for NETCONF based on XSD. A2) The issue will be discussed first by the base players Mark, Dave H, Bob Natale, J=FCrgen Sch=F6nw=E4lder and co-chairs [Mark] A3) and will be brought to the maillist to reach a consensus for the usage of data types in NETCONF [Mark]. Partial Lock RPC for NETCONF (Balazs Lengyel) Issue #1: Remove empty locks? Keep as it is. Issue #2: Does the granular locking put requirements on other protocols that night lock the database? Keep the text in document. The document is ready for WG last call? 8 in favor, no objections. B1) Update the document for clarifications [Balazs, done] B2) Bring the document to WGLC [Chairs] NETCONF over TLS (Mohamad Badra) Security AD Tim Polk does not see the additional value in the document since the password-based SSH transport is already mandatory. Tim Polk does not have any technical objections to the use of TLS out of the box if the WG decided so. The focus in the document should be on certificate-based TLS. C1) Summarize the WG discussion and take the comments of the security ADs Pasi Eronen and Tim Polk [Badra, mail sent]. C2) Bring AD comments to the maillist and ask for consensus [Badra]. NETCONF Notification Content (Sharon Chisholm) The WG has interest of doing some work on notification content (6 in room + 1 jabber in favour, no objections). The current charter does not cover this work and needs to be extended. D1) Chairs will prepare charter text proposal and ask the WG for comments and whether they are interested doing work on network content. [Chairs] Cheers, Bert & Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf . Bring the document to WGLC [Chairs, done] WG Last Call is running from Aug 10 till Aug24 [All WG members] PLEASE, all WG members should review and post their comments (also a "I have read it and am happy with it" is useful information). C) NETCONF over TLS (Mohamad Badra) C1) Need to focus on out-of-box usafge of TLS. Summarize the WG discussion and take the comments of the security ADs Pasi Eronen and Tim Polk [Badra, mail sent, follow still needs to happen.] C2) Bring (security) AD comments to the maillist and drive for consensus [Badra]. D) NETCONF Notification Content (Sharon Chisholm) The WG has interest of doing some work on notification content (6 in room + 1 jabber in favour, no objections). The current charter does not cover this work and needs to be extended. D1) Chairs will prepare charter text proposal and ask the WG for comments and whether they are interested doing work on network content. [Chairs] Bert and Mehmet ----- Original Message ----- = From: "Ersue, Mehmet (NSN - DE/Munich)" To: Cc: "ext Bert Wijnen (IETF)" Sent: Sunday, August 10, 2008 12:50 PM Subject: Summary of the NETCONF WG Session at IETF 72 and Action Points Dear NETCONF WG, after having sent out the preliminary minutes we need to confirm the results of the NETCONF session. =3D> [Topic owners] please start the necessary discussion or bring the action points "[A-D]n)" to the maillist as soon as possible. Below is the summary of the NETCONF WG session on TUESDAY, July 29, 2008 1850-1950. - We had 35 persons in the 1 hour NETCONF session. - We reviewed the status of the WG - NETCONF Notification draft has been published as RFC 5277. - We went through the chartered WG items and had a discussion and review of the documents. NETCONF Monitoring Schema (Mark Scott ) The NETCONF Monitoring needs some work before WGLC. Issue #1: Which terminology should be used? schema or model or data model ...? A1) The issue will be discussed on the maillist to try to converge to consensus [Mark]. Issue #2: lack of agreed XSD definitions for data types to use. The work on SMIv2-to-XSD translation in OPSAWG has a different focus and does not solve the problem of additional data types needed in NETCONF. PS: There was additional disscussion on this issue in the OPSAWG. The SMIv2-to-XSD document will be finalized asap to see how it impacts YANG data type usage. It has been proposed to define short-term data type usage for NETCONF based on XSD. A2) The issue will be discussed first by the base players Mark, Dave H, Bob Natale, J=FCrgen Sch=F6nw=E4lder and co-chairs [Mark] A3) and will be brought to the maillist to reach a consensus for the usage of data types in NETCONF [Mark]. Partial Lock RPC for NETCONF (Balazs Lengyel) Issue #1: Remove empty locks? Keep as it is. Issue #2: Does the granular locking put requirements on other protocols that night lock the database? Keep the text in document. The document is ready for WG last call? 8 in favor, no objections. B1) Update the document for clarifications [Balazs, done] B2) Bring the document to WGLC [Chairs] NETCONF over TLS (Mohamad Badra) Security AD Tim Polk does not see the additional value in the document since the password-based SSH transport is already mandatory. Tim Polk does not have any technical objections to the use of TLS out of the box if the WG decided so. The focus in the document should be on certificate-based TLS. C1) Summarize the WG discussion and take the comments of the security ADs Pasi Eronen and Tim Polk [Badra, mail sent]. C2) Bring AD comments to the maillist and ask for consensus [Badra]. NETCONF Notification Content (Sharon Chisholm) The WG has interest of doing some work on notification content (6 in room + 1 jabber in favour, no objections). The current charter does not cover this work and needs to be extended. D1) Chairs will prepare charter text proposal and ask the WG for comments and whether they are interested doing work on network content. [Chairs] Cheers, Bert & Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Aug 19 09:57:14 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7933A6CDF; Tue, 19 Aug 2008 09:57:14 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83FF93A6C9A for ; Tue, 19 Aug 2008 09:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=-0.992, 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 JHJXcZxbsQTd for ; Tue, 19 Aug 2008 09:57:12 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 4F03C3A6D27 for ; Tue, 19 Aug 2008 09:57:10 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m7JGv4vU020118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Aug 2008 18:57:04 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m7JGv4AR022261; Tue, 19 Aug 2008 18:57:04 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 18:57:04 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 18:57:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reminder for the WGLC of draft-ietf-netconf-partial-lock-03.txt WAS: [Netconf] WGLC for draft-ietf-netconf-partial-lock-03.txt Thread-Index: AckCHJpzg5HufuM6S6GzEL4UlO3dCA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 19 Aug 2008 16:57:04.0525 (UTC) FILETIME=[9B568BD0:01C9021C] Subject: [Netconf] Reminder for the WGLC of draft-ietf-netconf-partial-lock-03.txt WAS: WGLC for draft-ietf-netconf-partial-lock-03.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear NETCONF members, this is just a friendly reminder for the WGLC of the draft "Partial Lock RPC for NETCONF", which runs until August 24th. We did not have any comments on the Partial Lock draft yet. PLEASE REVIEW the document for WGLC and send your comments to the NETCONF maillist. Thank you! Mehmet > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) > Sent: Sunday, August 10, 2008 1:31 PM > To: netconf@ietf.org > Subject: [Netconf] WGLC for draft-ietf-netconf-partial-lock-03.txt > > > Hi All, > > as discussed in the NETCONF session Balazs updated > the draft "Partial Lock RPC for NETCONF" (see > http://tools.ietf.org/html/draft-ietf-netconf-partial-lock-03). > The draft has been discussed in this group and appears > to be stable for WGLC. From netconf-bounces@ietf.org Tue Aug 19 09:57:14 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7933A6CDF; Tue, 19 Aug 2008 09:57:14 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83FF93A6C9A for ; Tue, 19 Aug 2008 09:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=-0.992, 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 JHJXcZxbsQTd for ; Tue, 19 Aug 2008 09:57:12 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 4F03C3A6D27 for ; Tue, 19 Aug 2008 09:57:10 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m7JGv4vU020118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Aug 2008 18:57:04 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m7JGv4AR022261; Tue, 19 Aug 2008 18:57:04 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 18:57:04 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 18:57:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reminder for the WGLC of draft-ietf-netconf-partial-lock-03.txt WAS: [Netconf] WGLC for draft-ietf-netconf-partial-lock-03.txt Thread-Index: AckCHJpzg5HufuM6S6GzEL4UlO3dCA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 19 Aug 2008 16:57:04.0525 (UTC) FILETIME=[9B568BD0:01C9021C] Subject: [Netconf] Reminder for the WGLC of draft-ietf-netconf-partial-lock-03.txt WAS: WGLC for draft-ietf-netconf-partial-lock-03.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear NETCONF members, this is just a friendly reminder for the WGLC of the draft "Partial Lock RPC for NETCONF", which runs until August 24th. We did not have any comments on the Partial Lock draft yet. PLEASE REVIEW the document for WGLC and send your comments to the NETCONF maillist. Thank you! Mehmet > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) > Sent: Sunday, August 10, 2008 1:31 PM > To: netconf@ietf.org > Subject: [Netconf] WGLC for draft-ietf-netconf-partial-lock-03.txt > > > Hi All, > > as discussed in the NETCONF session Balazs updated > the draft "Partial Lock RPC for NETCONF" (see > http://tools.ietf.org/html/draft-ietf-netconf-partial-lock-03). > The draft has been discussed in this group and appears > to be stable for WGLC. > > W> > With this mail we start a WGLC for the Partial Lock > draft, which is proposed to publish as a Proposed > Standard RFC. > > The WGLC starts on August 10, 2008 and will run for > two weeks until August 24, 2008. > > Everybody on the NETCONF WG please review the > draft again and send your comments to the NETCONF > maillist. > > Thank you and looking forward for your reviews and > comments. > > Cheers, > Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ith this mail we start a WGLC for the Partial Lock > draft, which is proposed to publish as a Proposed > Standard RFC. > > The WGLC starts on August 10, 2008 and will run for > two weeks until August 24, 2008. > > Everybody on the NETCONF WG please review the > draft again and send your comments to the NETCONF > maillist. > > Thank you and looking forward for your reviews and > comments. > > Cheers, > Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Aug 19 14:05:58 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824E33A6A5A; Tue, 19 Aug 2008 14:05:58 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 911083A6A33 for ; Tue, 19 Aug 2008 14:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.456 X-Spam-Level: * X-Spam-Status: No, score=1.456 tagged_above=-999 required=5 tests=[AWL=-0.522, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmsTQbRIcqHf for ; Tue, 19 Aug 2008 14:05:57 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id EC3463A684B for ; Tue, 19 Aug 2008 14:05:56 -0700 (PDT) Received: (qmail 65031 invoked from network); 19 Aug 2008 21:05:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.143 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 19 Aug 2008 21:05:38 -0000 X-YMail-OSG: qMziOaUVM1mMZ5IE2JNOcyU3xeZmxUnv6BiIQ8qWiTBnQxROmnTwy4Yw_41O6P67FnsEM6a8PEoXJ8SigmVxjgGuAKFxvdmxqFls2ruE9Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AB35A1.4090403@netconfcentral.com> Date: Tue, 19 Aug 2008 14:05:37 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETCONF Subject: [Netconf] continue-on-error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, RFC 4741 is fairly vague on what exactly happens when continue-on-error is given as the edit-config error-option. (The test-option test-then-set is just as vague). It would be nice if an agent using YANG data models behaved in a deterministic manner for this knob. Is there any scoping that can be standardized, for example? I interpret continue-on-error to mean continue to the next child of (i.e., top-level element in an XML namespace). This is rather conservative, and maybe a finer granularity could be defined. But first, does anybody implement continue-on-error, and if so, what does it really mean in your agent? thanks, Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Aug 19 14:05:58 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824E33A6A5A; Tue, 19 Aug 2008 14:05:58 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 911083A6A33 for ; Tue, 19 Aug 2008 14:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.456 X-Spam-Level: * X-Spam-Status: No, score=1.456 tagged_above=-999 required=5 tests=[AWL=-0.522, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmsTQbRIcqHf for ; Tue, 19 Aug 2008 14:05:57 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id EC3463A684B for ; Tue, 19 Aug 2008 14:05:56 -0700 (PDT) Received: (qmail 65031 invoked from network); 19 Aug 2008 21:05:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.143 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 19 Aug 2008 21:05:38 -0000 X-YMail-OSG: qMziOaUVM1mMZ5IE2JNOcyU3xeZmxUnv6BiIQ8qWiTBnQxROmnTwy4Yw_41O6P67FnsEM6a8PEoXJ8SigmVxjgGuAKFxvdmxqFls2ruE9Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AB35A1.4090403@netconfcentral.com> Date: Tue, 19 Aug 2008 14:05:37 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETCONF Subject: [Netconf] continue-on-error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, RFC 4741 is fairly vague on what exactly happens when continue-on-error is given as the edit-config error-option. (The test-option test-then-set is just as vague). It would be nice if an agent using YANG data models behaved in a deterministic manner for this knob. Is there any scoping that can be standardized, for example? I interpret continue-on-error to mean continue to the next child of (i.e., top-level element in an XML namespace). This is rather conservative, and maybe a finer granularity could be defined. But first, does anybody implement continue-on-error, and if so, what does it really mean in your agent? thanks, Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Aug 19 15:13:31 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF54D3A687D; Tue, 19 Aug 2008 15:13:31 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A44533A693E for ; Tue, 19 Aug 2008 15:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[AWL=0.215, 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 Ynck0AfykU9P for ; Tue, 19 Aug 2008 15:13: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 D54953A684B for ; Tue, 19 Aug 2008 15:13:29 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 25B0B76C423; Wed, 20 Aug 2008 00:12:39 +0200 (CEST) Date: Wed, 20 Aug 2008 00:12:32 +0200 (CEST) Message-Id: <20080820.001232.235877409.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48AB35A1.4090403@netconfcentral.com> References: <48AB35A1.4090403@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] continue-on-error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > Hi, > > RFC 4741 is fairly vague on what exactly happens when > continue-on-error is given as the edit-config error-option. > (The test-option test-then-set is just as vague). Yes, the "continue" part is unclear, and also the "error" part is unclear. > Is there any scoping that can be standardized, for example? The motivation for this that I've been told is to support something like when you upload an old cli backup file, and some commands are now obsolete, and you just want to ignore them. For this particular use case, I think it could make sense to define "continue" to mean skip the faulty XML element, and "error" to occur when an unknown element is encountered. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Aug 19 15:13:31 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF54D3A687D; Tue, 19 Aug 2008 15:13:31 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A44533A693E for ; Tue, 19 Aug 2008 15:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[AWL=0.215, 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 Ynck0AfykU9P for ; Tue, 19 Aug 2008 15:13: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 D54953A684B for ; Tue, 19 Aug 2008 15:13:29 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 25B0B76C423; Wed, 20 Aug 2008 00:12:39 +0200 (CEST) Date: Wed, 20 Aug 2008 00:12:32 +0200 (CEST) Message-Id: <20080820.001232.235877409.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48AB35A1.4090403@netconfcentral.com> References: <48AB35A1.4090403@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] continue-on-error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > Hi, > > RFC 4741 is fairly vague on what exactly happens when > continue-on-error is given as the edit-config error-option. > (The test-option test-then-set is just as vague). Yes, the "continue" part is unclear, and also the "error" part is unclear. > Is there any scoping that can be standardized, for example? The motivation for this that I've been told is to support something like when you upload an old cli backup file, and some commands are now obsolete, and you just want to ignore them. For this particular use case, I think it could make sense to define "continue" to mean skip the faulty XML element, and "error" to occur when an unknown element is encountered. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Aug 20 14:42:45 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564933A6980; Wed, 20 Aug 2008 14:42:45 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70B8E3A6A68 for ; Wed, 20 Aug 2008 14:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 XePxfKDxTdye for ; Wed, 20 Aug 2008 14:38:59 -0700 (PDT) Received: from chip3og65.obsmtp.com (chip3og65.obsmtp.com [64.18.14.207]) by core3.amsl.com (Postfix) with ESMTP id 7B1343A6A31 for ; Wed, 20 Aug 2008 14:38:59 -0700 (PDT) Received: from source ([66.129.228.6]) by chip3ob65.postini.com ([64.18.6.12]) with SMTP; Wed, 20 Aug 2008 14:38:07 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 14:37:51 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 14:37:50 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Aug 2008 14:37:50 -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 m7KLbnu72453; Wed, 20 Aug 2008 14:37:49 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7KLYLOZ003375; Wed, 20 Aug 2008 21:34:21 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808202134.m7KLYLOZ003375@idle.juniper.net> To: Andy Bierman In-reply-to: <48AB35A1.4090403@netconfcentral.com> Date: Wed, 20 Aug 2008 17:34:21 -0400 From: Phil Shafer X-OriginalArrivalTime: 20 Aug 2008 21:37:50.0130 (UTC) FILETIME=[FE83A120:01C9030C] Cc: NETCONF Subject: Re: [Netconf] continue-on-error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >But first, does anybody implement continue-on-error, >and if so, what does it really mean in your agent? "continue-on-error" means "do your best to keep going". "your best" can't be defined easily, since you're facing input that contains errors. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Aug 20 14:42:45 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564933A6980; Wed, 20 Aug 2008 14:42:45 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70B8E3A6A68 for ; Wed, 20 Aug 2008 14:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 XePxfKDxTdye for ; Wed, 20 Aug 2008 14:38:59 -0700 (PDT) Received: from chip3og65.obsmtp.com (chip3og65.obsmtp.com [64.18.14.207]) by core3.amsl.com (Postfix) with ESMTP id 7B1343A6A31 for ; Wed, 20 Aug 2008 14:38:59 -0700 (PDT) Received: from source ([66.129.228.6]) by chip3ob65.postini.com ([64.18.6.12]) with SMTP; Wed, 20 Aug 2008 14:38:07 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 14:37:51 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 14:37:50 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Aug 2008 14:37:50 -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 m7KLbnu72453; Wed, 20 Aug 2008 14:37:49 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7KLYLOZ003375; Wed, 20 Aug 2008 21:34:21 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808202134.m7KLYLOZ003375@idle.juniper.net> To: Andy Bierman In-reply-to: <48AB35A1.4090403@netconfcentral.com> Date: Wed, 20 Aug 2008 17:34:21 -0400 From: Phil Shafer X-OriginalArrivalTime: 20 Aug 2008 21:37:50.0130 (UTC) FILETIME=[FE83A120:01C9030C] Cc: NETCONF Subject: Re: [Netconf] continue-on-error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >But first, does anybody implement continue-on-error, >and if so, what does it really mean in your agent? "continue-on-error" means "do your best to keep going". "your best" can't be defined easily, since you're facing input that contains errors. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 06:02:32 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E943028C0E5; Thu, 21 Aug 2008 06:02:32 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AEF73A67B6 for ; Thu, 21 Aug 2008 05:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWuoiWNVtSmv for ; Thu, 21 Aug 2008 05:56:43 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 244E23A6B28 for ; Thu, 21 Aug 2008 05:56:43 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DEADF207ED; Thu, 21 Aug 2008 14:56:14 +0200 (CEST) X-AuditID: c1b4fb3c-ad8cdbb0000015b5-0a-48ad65ee3430 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CC31A205D6; Thu, 21 Aug 2008 14:56:14 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 14:56:14 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 14:56:14 +0200 Message-ID: <48AD6595.7020603@ericsson.com> Date: Thu, 21 Aug 2008 14:54:45 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: In-Reply-To: X-OriginalArrivalTime: 21 Aug 2008 12:56:14.0520 (UTC) FILETIME=[4B4A4380:01C9038D] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list Subject: [Netconf] New work: 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello Bert, Mehmet, In the Netmod WG (mostly the same people I assume) I raised the issue of getting the "with-defaults" feature documented/standardized/RFC-d. The feature will be useful even without YANG, but even more so once YANG is adopted. IMHO there is a consensus about the need for the feature. Andy Bierman already wrote a draft (http://tools.ietf.org/html/draft-bierman-ncx-ext-00) that could be used as a a starting point; I am only referring to chapter "2.2. with-defaults Attribute", not the rest of the draft. I assume Andy is willing to work on the topic, but I am definitely available for this. I would like to have this added to the WG charter, proposed text: "5. With-defaults feature: The NETCONF working group will define a mechanism whereby the Netconf manager can control, wFrom netconf-bounces@ietf.org Thu Aug 21 06:02:32 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E943028C0E5; Thu, 21 Aug 2008 06:02:32 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AEF73A67B6 for ; Thu, 21 Aug 2008 05:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWuoiWNVtSmv for ; Thu, 21 Aug 2008 05:56:43 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 244E23A6B28 for ; Thu, 21 Aug 2008 05:56:43 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DEADF207ED; Thu, 21 Aug 2008 14:56:14 +0200 (CEST) X-AuditID: c1b4fb3c-ad8cdbb0000015b5-0a-48ad65ee3430 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CC31A205D6; Thu, 21 Aug 2008 14:56:14 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 14:56:14 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 14:56:14 +0200 Message-ID: <48AD6595.7020603@ericsson.com> Date: Thu, 21 Aug 2008 14:54:45 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: In-Reply-To: X-OriginalArrivalTime: 21 Aug 2008 12:56:14.0520 (UTC) FILETIME=[4B4A4380:01C9038D] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list Subject: [Netconf] New work: 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello Bert, Mehmet, In the Netmod WG (mostly the same people I assume) I raised the issue of getting the "with-defaults" feature documented/standardized/RFC-d. The feature will be useful even without YANG, but even more so once YANG is adopted. IMHO there is a consensus about the need for the feature. Andy Bierman already wrote a draft (http://tools.ietf.org/html/draft-bierman-ncx-ext-00) that could be used as a a starting point; I am only referring to chapter "2.2. with-defaults Attribute", not the rest of the draft. I assume Andy is willing to work on the topic, but I am definitely available for this. I would like to have this added to the WG charter, proposed text: "5. With-defaults feature: The NETCONF working group will define a mechanism whereby the Netconf manager can conthether the Netconf server shall include default values in the reply to the get, get-config and copy-config operations." Comments? Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf rol, whether the Netconf server shall include default values in the reply to the get, get-config and copy-config operations." Comments? Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 07:42:21 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C47BA3A6AF4; Thu, 21 Aug 2008 07:42:21 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDF5F3A684A for ; Thu, 21 Aug 2008 07:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 TxLErBMrRM0v for ; Thu, 21 Aug 2008 07:26:58 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id EA96428C0F8 for ; Thu, 21 Aug 2008 07:26:51 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Thu, 21 Aug 2008 07:25:33 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Aug 2008 07:25:16 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Aug 2008 07:25:15 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 07:25:14 -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 m7LEPDu37463; Thu, 21 Aug 2008 07:25:13 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7LELiWt013742; Thu, 21 Aug 2008 14:21:44 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808211421.m7LELiWt013742@idle.juniper.net> To: Balazs Lengyel In-reply-to: <48AD6595.7020603@ericsson.com> Date: Thu, 21 Aug 2008 10:21:44 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Aug 2008 14:25:14.0235 (UTC) FILETIME=[BA021CB0:01C90399] Cc: netconf mailing list Subject: Re: [Netconf] New work: 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel writes: >I would like to have this added to the WG charter, proposed text: Would writing a new draft be the place to start? Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 07:42:21 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C47BA3A6AF4; Thu, 21 Aug 2008 07:42:21 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDF5F3A684A for ; Thu, 21 Aug 2008 07:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 TxLErBMrRM0v for ; Thu, 21 Aug 2008 07:26:58 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id EA96428C0F8 for ; Thu, 21 Aug 2008 07:26:51 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Thu, 21 Aug 2008 07:25:33 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Aug 2008 07:25:16 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Aug 2008 07:25:15 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 07:25:14 -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 m7LEPDu37463; Thu, 21 Aug 2008 07:25:13 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7LELiWt013742; Thu, 21 Aug 2008 14:21:44 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808211421.m7LELiWt013742@idle.juniper.net> To: Balazs Lengyel In-reply-to: <48AD6595.7020603@ericsson.com> Date: Thu, 21 Aug 2008 10:21:44 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Aug 2008 14:25:14.0235 (UTC) FILETIME=[BA021CB0:01C90399] Cc: netconf mailing list Subject: Re: [Netconf] New work: 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel writes: >I would like to have this added to the WG charter, proposed text: Would writing a new draft be the place to start? Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 07:42:55 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2085728C111; Thu, 21 Aug 2008 07:42:55 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54B243A69B1 for ; Thu, 21 Aug 2008 07:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 5wL1zJ+R2upR for ; Thu, 21 Aug 2008 07:35:41 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 171453A6829 for ; Thu, 21 Aug 2008 07:35:39 -0700 (PDT) Received: (qmail 1346 invoked from network); 21 Aug 2008 13:41:10 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 21 Aug 2008 13:41:10 -0000 Message-ID: <3A5196BD34544B23B752D6011C85A1A2@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Balazs Lengyel" References: <48AD6595.7020603@ericsson.com> In-Reply-To: <48AD6595.7020603@ericsson.com> Date: Thu, 21 Aug 2008 15:10:47 +0200 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: netconf mailing list Subject: Re: [Netconf] New work: 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs, Thanks for your input. WG, pls express your opinion on this possible new work-item. Bert ----- Original Message ----- From: "Balazs Lengyel" To: "Bert Wijnen (IETF)" Cc: "Ersue, Mehmet (NSN - DE/Muenich)" ; "netconf mailing list" Sent: Thursday, August 21, 2008 2:54 PM Subject: New work: with-defaults > Hello Bert, Mehmet, > In the Netmod WG (mostly the same people I assume) I raised the issue of > getting the "with-defaults" feature documented/standardized/RFC-d. The > feature will be useful even without YANG, but even more so once YANG is > adopted. IMHO there is a consensus about the need for the feature. > > Andy Bierman already wrote a draft > (http://tools.ietf.org/html/draft-bierman-ncx-ext-00) that could be used > as a a starting point; I am only referring to chapter "2.2. with-defaults > Attribute", not the rest of the draft. I assume Andy is willing to work on > the topic, but I am definitely available for this. > > I would like to have this added to the WG charter, proposed text: > > "5. With-defaults feature: The NETCONF working group will define a > mechanism whereby the Netconf manager can control, whether the Netconf > server shall include default values in the reply to the get, get-config > and copy-config operations." > > Comments? > Balazs > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 07:42:55 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2085728C111; Thu, 21 Aug 2008 07:42:55 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54B243A69B1 for ; Thu, 21 Aug 2008 07:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 5wL1zJ+R2upR for ; Thu, 21 Aug 2008 07:35:41 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 171453A6829 for ; Thu, 21 Aug 2008 07:35:39 -0700 (PDT) Received: (qmail 1346 invoked from network); 21 Aug 2008 13:41:10 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 21 Aug 2008 13:41:10 -0000 Message-ID: <3A5196BD34544B23B752D6011C85A1A2@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Balazs Lengyel" References: <48AD6595.7020603@ericsson.com> In-Reply-To: <48AD6595.7020603@ericsson.com> Date: Thu, 21 Aug 2008 15:10:47 +0200 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: netconf mailing list Subject: Re: [Netconf] New work: 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs, Thanks for your input. WG, pls express your opinion on this possible new work-item. Bert ----- Original Message ----- From: "Balazs Lengyel" To: "Bert Wijnen (IETF)" Cc: "Ersue, Mehmet (NSN - DE/Muenich)" ; "netconf mailing list" Sent: Thursday, August 21, 2008 2:54 PM Subject: New work: with-defaults > Hello Bert, Mehmet, > In the Netmod WG (mostly the same people I assume) I raised the issue of > getting the "with-defaults" feature documented/standardized/RFC-d. The > feature will be useful even without YANG, but even more so once YANG is > adopted. IMHO there is a consensus about the need for the feature. > > Andy Bierman already wrote a draft > (http://tools.ietf.org/html/draft-bierman-ncx-ext-00) that could be used > as a a starting point; I am only referring to chapter "2.2. with-defaults > Attribute", not the rest of the draft. I assume Andy is willing to work on > the topic, but I am definitely available for this. > > I would like to have this added to the WG charter, proposed text: > > "5. With-defaults feature: The NETCONF working group will define a > mechanism whereby the Netconf manager can control, whether the Netconf > server shall include default values in the reply to the get, get-config > and copy-config operations." > > Comments? > Balazs > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 07:47:13 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780B83A68BC; Thu, 21 Aug 2008 07:47:13 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B46C3A69A8 for ; Thu, 21 Aug 2008 07:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AN-+lkOnl0V0 for ; Thu, 21 Aug 2008 07:47:11 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5A3513A69A4 for ; Thu, 21 Aug 2008 07:47:11 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7EB6722484; Thu, 21 Aug 2008 16:43:52 +0200 (CEST) X-AuditID: c1b4fb3e-a9e87bb000007a96-7b-48ad7f28c69e Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5F64422483; Thu, 21 Aug 2008 16:43:52 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 16:43:51 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 16:43:51 +0200 Message-ID: <48AD7ECE.7010406@ericsson.com> Date: Thu, 21 Aug 2008 16:42:22 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer References: <200808211421.m7LELiWt013742@idle.juniper.net> In-Reply-To: <200808211421.m7LELiWt013742@idle.juniper.net> X-OriginalArrivalTime: 21 Aug 2008 14:43:51.0457 (UTC) FILETIME=[53ECA910:01C9039C] X-Brightmail-Tracker: AAAAAA== Cc: Andy Bierman , netconf mailing list Subject: Re: [Netconf] New work: 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, Definitely, but i would like to know two things first: 1) Is there some support for this, can we get it chartered? Pleaser raise your voice if you support it? 2) As Andy has a draft on the topic, does he want to do this? Balazs Phil Shafer wrote: > Balazs Lengyel writes: >> I would like to have this added to the WG charter, proposed text: > > Would writing a new draft be the place to start? > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 07:47:13 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780B83A68BC; Thu, 21 Aug 2008 07:47:13 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B46C3A69A8 for ; Thu, 21 Aug 2008 07:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AN-+lkOnl0V0 for ; Thu, 21 Aug 2008 07:47:11 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5A3513A69A4 for ; Thu, 21 Aug 2008 07:47:11 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7EB6722484; Thu, 21 Aug 2008 16:43:52 +0200 (CEST) X-AuditID: c1b4fb3e-a9e87bb000007a96-7b-48ad7f28c69e Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5F64422483; Thu, 21 Aug 2008 16:43:52 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 16:43:51 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 16:43:51 +0200 Message-ID: <48AD7ECE.7010406@ericsson.com> Date: Thu, 21 Aug 2008 16:42:22 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer References: <200808211421.m7LELiWt013742@idle.juniper.net> In-Reply-To: <200808211421.m7LELiWt013742@idle.juniper.net> X-OriginalArrivalTime: 21 Aug 2008 14:43:51.0457 (UTC) FILETIME=[53ECA910:01C9039C] X-Brightmail-Tracker: AAAAAA== Cc: Andy Bierman , netconf mailing list Subject: Re: [Netconf] New work: 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, Definitely, but i would like to know two things first: 1) Is there some support for this, can we get it chartered? Pleaser raise your voice if you support it? 2) As Andy has a draft on the topic, does he want to do this? Balazs Phil Shafer wrote: > Balazs Lengyel writes: >> I would like to have this added to the WG charter, proposed text: > > Would writing a new draft be the place to start? > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 07:59:50 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E8D3A68AD; Thu, 21 Aug 2008 07:59:50 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B27F73A68AD for ; Thu, 21 Aug 2008 07:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=0.418, 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 0ttmSfhCom4i for ; Thu, 21 Aug 2008 07:59:47 -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 456BF3A67F9 for ; Thu, 21 Aug 2008 07:59:47 -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 46259616004; Thu, 21 Aug 2008 16:59:45 +0200 (CEST) Date: Thu, 21 Aug 2008 16:59:45 +0200 (CEST) Message-Id: <20080821.165945.184835501.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <3A5196BD34544B23B752D6011C85A1A2@BertLaptop> References: <48AD6595.7020603@ericsson.com> <3A5196BD34544B23B752D6011C85A1A2@BertLaptop> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] New work: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Bert Wijnen \(IETF\)" wrote: > WG, pls express your opinion on this possible new work-item. I support this. (And have it implemented the way Andy describes it). /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 07:59:50 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E8D3A68AD; Thu, 21 Aug 2008 07:59:50 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B27F73A68AD for ; Thu, 21 Aug 2008 07:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=0.418, 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 0ttmSfhCom4i for ; Thu, 21 Aug 2008 07:59:47 -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 456BF3A67F9 for ; Thu, 21 Aug 2008 07:59:47 -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 46259616004; Thu, 21 Aug 2008 16:59:45 +0200 (CEST) Date: Thu, 21 Aug 2008 16:59:45 +0200 (CEST) Message-Id: <20080821.165945.184835501.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <3A5196BD34544B23B752D6011C85A1A2@BertLaptop> References: <48AD6595.7020603@ericsson.com> <3A5196BD34544B23B752D6011C85A1A2@BertLaptop> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] New work: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Bert Wijnen \(IETF\)" wrote: > WG, pls express your opinion on this possible new work-item. I support this. (And have it implemented the way Andy describes it). /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 08:03:03 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E39B3A6829; Thu, 21 Aug 2008 08:03:03 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6C03A680E for ; Thu, 21 Aug 2008 08:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[AWL=0.220, 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 6fneg0ROWHWv for ; Thu, 21 Aug 2008 08:02:53 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 42F6C3A67F4 for ; Thu, 21 Aug 2008 08:02:53 -0700 (PDT) Received: (qmail 15084 invoked from network); 21 Aug 2008 15:02:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 21 Aug 2008 15:02:23 -0000 X-YMail-OSG: EoMzHB0VM1n8zkN7DFtQ3mcCYw.HIRS6oVJFcQBfkum.Pkg.RZfS5VNtbzsxT59_xQ2edy1ZH2mjcgaaH9nTLcHE2y_R.oc6gSfUJMXVkg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AD837D.5020408@netconfcentral.com> Date: Thu, 21 Aug 2008 08:02:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Balazs Lengyel References: <200808211421.m7LELiWt013742@idle.juniper.net> <48AD7ECE.7010406@ericsson.com> In-Reply-To: <48AD7ECE.7010406@ericsson.com> Cc: Andy Bierman , netconf mailing list Subject: Re: [Netconf] New work: 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel wrote: > Hello, > Definitely, but i would like to know two things first: > 1) Is there some support for this, can we get it chartered? Pleaser > raise your voice if you support it? > 2) As Andy has a draft on the topic, does he want to do this? yes -- I think the major issues are: 1) add a capability URI for 'with-defaults' support 2) use augment to add new optional leafs to copy-config, get-config, and get (type empty), instead of an XML attribute in the element 3) with-defaults-default leaf in netconf-state DM (or separate DM?) - is this read-only or just min-access read-only? - should this be required (read-only) even if with-defaults capability not supported? Balazs and I have agreed to work on a draft, so hopefully in a few weeks, a new draft addressing defaults will be out. > Balazs > > Phil Shafer wrote: >> Balazs Lengyel writes: >>> I would like to have this added to the WG charter, proposed text: >> >> Would writing a new draft be the place to start? >> Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 08:03:03 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E39B3A6829; Thu, 21 Aug 2008 08:03:03 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6C03A680E for ; Thu, 21 Aug 2008 08:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[AWL=0.220, 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 6fneg0ROWHWv for ; Thu, 21 Aug 2008 08:02:53 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 42F6C3A67F4 for ; Thu, 21 Aug 2008 08:02:53 -0700 (PDT) Received: (qmail 15084 invoked from network); 21 Aug 2008 15:02:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 21 Aug 2008 15:02:23 -0000 X-YMail-OSG: EoMzHB0VM1n8zkN7DFtQ3mcCYw.HIRS6oVJFcQBfkum.Pkg.RZfS5VNtbzsxT59_xQ2edy1ZH2mjcgaaH9nTLcHE2y_R.oc6gSfUJMXVkg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AD837D.5020408@netconfcentral.com> Date: Thu, 21 Aug 2008 08:02:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Balazs Lengyel References: <200808211421.m7LELiWt013742@idle.juniper.net> <48AD7ECE.7010406@ericsson.com> In-Reply-To: <48AD7ECE.7010406@ericsson.com> Cc: Andy Bierman , netconf mailing list Subject: Re: [Netconf] New work: 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel wrote: > Hello, > Definitely, but i would like to know two things first: > 1) Is there some support for this, can we get it chartered? Pleaser > raise your voice if you support it? > 2) As Andy has a draft on the topic, does he want to do this? yes -- I think the major issues are: 1) add a capability URI for 'with-defaults' support 2) use augment to add new optional leafs to copy-config, get-config, and get (type empty), instead of an XML attribute in the element 3) with-defaults-default leaf in netconf-state DM (or separate DM?) - is this read-only or just min-access read-only? - should this be required (read-only) even if with-defaults capability not supported? Balazs and I have agreed to work on a draft, so hopefully in a few weeks, a new draft addressing defaults will be out. > Balazs > > Phil Shafer wrote: >> Balazs Lengyel writes: >>> I would like to have this added to the WG charter, proposed text: >> >> Would writing a new draft be the place to start? >> Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 08:56:51 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B112F3A6B4F; Thu, 21 Aug 2008 08:56:51 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9BB23A6767 for ; Thu, 21 Aug 2008 08:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[AWL=-0.824, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNINr0AApRHk for ; Thu, 21 Aug 2008 08:46:32 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 8E4813A68B9 for ; Thu, 21 Aug 2008 08:46:29 -0700 (PDT) Received: (qmail 87882 invoked from network); 21 Aug 2008 14:40:41 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 21 Aug 2008 14:40:41 -0000 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Balazs Lengyel" , "Phil Shafer" References: <200808211421.m7LELiWt013742@idle.juniper.net> In-Reply-To: <200808211421.m7LELiWt013742@idle.juniper.net> Date: Thu, 21 Aug 2008 16:38:39 +0200 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: netconf mailing list Subject: Re: [Netconf] New work: 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org That would certainly help. But since some of the dieas are already documented in a draft from Andy (to which Balazs pointed), people may be able to state their opinion already. Bert ----- Original Message ----- From: "Phil Shafer" To: "Balazs Lengyel" Cc: "Bert Wijnen (IETF)" ; "netconf mailing list" Sent: Thursday, August 21, 2008 4:21 PM Subject: Re: [Netconf] New work: with-defaults > Balazs Lengyel writes: >>I would like to have this added to the WG charter, proposed text: > > Would writing a new draft be the place to start? > > Thanks, > Phil > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 08:56:51 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B112F3A6B4F; Thu, 21 Aug 2008 08:56:51 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9BB23A6767 for ; Thu, 21 Aug 2008 08:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[AWL=-0.824, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNINr0AApRHk for ; Thu, 21 Aug 2008 08:46:32 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 8E4813A68B9 for ; Thu, 21 Aug 2008 08:46:29 -0700 (PDT) Received: (qmail 87882 invoked from network); 21 Aug 2008 14:40:41 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 21 Aug 2008 14:40:41 -0000 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Balazs Lengyel" , "Phil Shafer" References: <200808211421.m7LELiWt013742@idle.juniper.net> In-Reply-To: <200808211421.m7LELiWt013742@idle.juniper.net> Date: Thu, 21 Aug 2008 16:38:39 +0200 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: netconf mailing list Subject: Re: [Netconf] New work: 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org That would certainly help. But since some of the dieas are already documented in a draft from Andy (to which Balazs pointed), people may be able to state their opinion already. Bert ----- Original Message ----- From: "Phil Shafer" To: "Balazs Lengyel" Cc: "Bert Wijnen (IETF)" ; "netconf mailing list" Sent: Thursday, August 21, 2008 4:21 PM Subject: Re: [Netconf] New work: with-defaults > Balazs Lengyel writes: >>I would like to have this added to the WG charter, proposed text: > > Would writing a new draft be the place to start? > > Thanks, > Phil > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 10:41:13 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510CB3A69B2; Thu, 21 Aug 2008 10:41:13 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0703A69B2 for ; Thu, 21 Aug 2008 10:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.187, 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 EOd8qKgEvroH for ; Thu, 21 Aug 2008 10:39:39 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id B1D323A69A7 for ; Thu, 21 Aug 2008 10:39:39 -0700 (PDT) Received: (qmail 59523 invoked from network); 21 Aug 2008 17:37:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 21 Aug 2008 17:37:36 -0000 X-YMail-OSG: 2DDt978VM1nD2.YjCUzxEWG5yNN8TI1Bc3wVfaV0XYgJAb7Lo2pS.jCsJenkt0oyFHQ.Vnx4xeh.wS1U1hkjmdUrN5sFlwacMPuhq741JagMbQB8fG2O.MPv4Jja55U- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48ADA7DE.3030108@netconfcentral.com> Date: Thu, 21 Aug 2008 10:37:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <200808111537.m7BFbSS2098789@idle.juniper.net> <48A060AC.70203@netconfcentral.com> <20080811.203257.128375678.mbj@tail-f.com> In-Reply-To: <20080811.203257.128375678.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > I asked this question to the netconf WG but it of course impacts what > will be done in netmod. Going back to my original question: > > Section 4.2 of rfc4741 says: > > The response name and response data are encoded as the contents of > the element. The name of the reply is an element > directly inside the element, and any data is encoded > inside this element. > > Does the WG think that this text is correct, and the XSD wrong? > > If so, should I interpret "the reply is an element" as saying that > there can be *one* reply and never more? For example, is this > illegal: > > > > 10.1.2.3 > > > > 10.1.2.3 > 10.1.2.3 > 56 > > 5 > 0 > 100 > > no response > > > Any chance of a resolution on this detail? If the XSD is normative, then YANG rpc output statements may only contain 1 element which gets inserted From netconf-bounces@ietf.org Thu Aug 21 10:41:13 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510CB3A69B2; Thu, 21 Aug 2008 10:41:13 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0703A69B2 for ; Thu, 21 Aug 2008 10:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.187, 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 EOd8qKgEvroH for ; Thu, 21 Aug 2008 10:39:39 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id B1D323A69A7 for ; Thu, 21 Aug 2008 10:39:39 -0700 (PDT) Received: (qmail 59523 invoked from network); 21 Aug 2008 17:37:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 21 Aug 2008 17:37:36 -0000 X-YMail-OSG: 2DDt978VM1nD2.YjCUzxEWG5yNN8TI1Bc3wVfaV0XYgJAb7Lo2pS.jCsJenkt0oyFHQ.Vnx4xeh.wS1U1hkjmdUrN5sFlwacMPuhq741JagMbQB8fG2O.MPv4Jja55U- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48ADA7DE.3030108@netconfcentral.com> Date: Thu, 21 Aug 2008 10:37:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Martin Bjorklund References: <200808111537.m7BFbSS2098789@idle.juniper.net> <48A060AC.70203@netconfcentral.com> <20080811.203257.128375678.mbj@tail-f.com> In-Reply-To: <20080811.203257.128375678.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > I asked this question to the netconf WG but it of course impacts what > will be done in netmod. Going back to my original question: > > Section 4.2 of rfc4741 says: > > The response name and response data are encoded as the contents of > the element. The name of the reply is an element > directly inside the element, and any data is encoded > inside this element. > > Does the WG think that this text is correct, and the XSD wrong? > > If so, should I interpret "the reply is an element" as saying that > there can be *one* reply and never more? For example, is this > illegal: > > > > 10.1.2.3 > > > > 10.1.2.3 > 10.1.2.3 > 56 > > 5 > 0 > 100 > > no response > > > Any chance of a resolution on this detail? If the XSD is normative, then YANG rpc output statements may only contain 1 element which gets insas a child node of the NETCONF 1.0 'data' element. If the XSD is wrong, then the YANG output statement may contain more than 1 element, with any name, and any namespace, which are child nodes of the element. I agree with Phil's interpretation, i.e., that the XSD applies to the RPC methods defined in RFC 4741, and not every possible RPC method, especially those in vendor namespaces. The results from the example above would actually look more like this: 10.1.2.3 10.1.2.3 56 5 0 100 no response IMO, this should be allowed. The only rule would be that all instances must be encoded before any data nodes (as it is now). It really wouldn't affect a vendor's deployed agents, since all the 'official' RPCs would also be valid with this clarified interpretation. > > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf erted as a child node of the NETCONF 1.0 'data' element. If the XSD is wrong, then the YANG output statement may contain more than 1 element, with any name, and any namespace, which are child nodes of the element. I agree with Phil's interpretation, i.e., that the XSD applies to the RPC methods defined in RFC 4741, and not every possible RPC method, especially those in vendor namespaces. The results from the example above would actually look more like this: 10.1.2.3 10.1.2.3 56 5 0 100 no response IMO, this should be allowed. The only rule would be that all instances must be encoded before any data nodes (as it is now). It really wouldn't affect a vendor's deployed agents, since all the 'official' RPCs would also be valid with this clarified interpretation. > > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 10:42:06 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55D3E3A6914; Thu, 21 Aug 2008 10:42:06 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F11303A68DA for ; Thu, 21 Aug 2008 10:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.425 X-Spam-Level: X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=0.824, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WE-0Ep3A+qX for ; Thu, 21 Aug 2008 10:41:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8870C3A6892 for ; Thu, 21 Aug 2008 10:41:53 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7CBBCC00A7; Thu, 21 Aug 2008 19:41:14 +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 f2uKjYKs5A1f; Thu, 21 Aug 2008 19:41: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 5F37FC00C7; Thu, 21 Aug 2008 19:41:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7FABE69A521; Thu, 21 Aug 2008 19:41:06 +0200 (CEST) Date: Thu, 21 Aug 2008 19:41:06 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080821174106.GB21875@elstar.local> Mail-Followup-To: Andy Bierman , Balazs Lengyel , Andy Bierman , netconf mailing list References: <200808211421.m7LELiWt013742@idle.juniper.net> <48AD7ECE.7010406@ericsson.com> <48AD837D.5020408@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48AD837D.5020408@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Andy Bierman , netconf mailing list Subject: Re: [Netconf] New work: with-defaults X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Thu, Aug 21, 2008 at 08:02:21AM -0700, Andy Bierman wrote: > 3) with-defaults-default leaf in netconf-state DM (or separate DM?) > - is this read-only or just min-access read-only? > - should this be required (read-only) even if with-defaults > capability not supported? Why is this needed? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 10:42:06 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55D3E3A6914; Thu, 21 Aug 2008 10:42:06 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F11303A68DA for ; Thu, 21 Aug 2008 10:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.425 X-Spam-Level: X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=0.824, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WE-0Ep3A+qX for ; Thu, 21 Aug 2008 10:41:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8870C3A6892 for ; Thu, 21 Aug 2008 10:41:53 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7CBBCC00A7; Thu, 21 Aug 2008 19:41:14 +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 f2uKjYKs5A1f; Thu, 21 Aug 2008 19:41: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 5F37FC00C7; Thu, 21 Aug 2008 19:41:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7FABE69A521; Thu, 21 Aug 2008 19:41:06 +0200 (CEST) Date: Thu, 21 Aug 2008 19:41:06 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080821174106.GB21875@elstar.local> Mail-Followup-To: Andy Bierman , Balazs Lengyel , Andy Bierman , netconf mailing list References: <200808211421.m7LELiWt013742@idle.juniper.net> <48AD7ECE.7010406@ericsson.com> <48AD837D.5020408@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48AD837D.5020408@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Andy Bierman , netconf mailing list Subject: Re: [Netconf] New work: with-defaults X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Thu, Aug 21, 2008 at 08:02:21AM -0700, Andy Bierman wrote: > 3) with-defaults-default leaf in netconf-state DM (or separate DM?) > - is this read-only or just min-access read-only? > - should this be required (read-only) even if with-defaults > capability not supported? Why is this needed? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 11:34:32 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B595E3A69A7; Thu, 21 Aug 2008 11:34:32 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94EE03A6A7A for ; Thu, 21 Aug 2008 11:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, 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 eHjuHCDzGnut for ; Thu, 21 Aug 2008 11:33:36 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id D1E283A69E0 for ; Thu, 21 Aug 2008 11:33:35 -0700 (PDT) Received: (qmail 41013 invoked from network); 21 Aug 2008 18:33:26 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 21 Aug 2008 18:33:26 -0000 Message-ID: From: "Bert Wijnen \(IETF\)" To: "netconf mailing list" Date: Thu, 21 Aug 2008 20:33:15 +0200 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: [Netconf] NETCONF ovet TLS changes proposed X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org WG members, The Security ADs have given their feedback on this document, see attached email from Pasi Eronen at the bottom. As a result, Badra wants to remove all text related to password. authetication. IT only makes sense that he does so if we have WG consensus on that. My personal feeling from the mailing list discussions and from the last session at IETF72 is that the WG indeed does agree with that removal. Please speak up before September 1st if you do not agree. Thanks, Bert Wijnen (sepaking as WG chair) ----- Original Message ----- From: "Badra" To: "Bert Wijnen (IETF)" ; "Ersue, Mehmet (NSN - DE/Muenich)" Sent: Thursday, August 21, 2008 6:43 PM Subject: NETCONF ovet TLS: Mail > Dear Bert, > > I would like to send the following text to the mailing list, but I prefer > that you of Mehmet do that since it includes a WG consensus request. > Please > advice. > > > Dear all, > > > > Pasi Eronen and Tim Polk (Security Ads) have revised the document during > the > last IETF session (see minutes) and via e-mail from Pasi (see below). > > > > Early versions of the document didn't specify the password-based > authentication and this later has been added to the document since some > members wanted ala unix authentication, which why PSK derivation from > passwords has been specified. > > > > Based on the comments from the Security ADs: the main reason for using > TLS; > especially considering that the document can't anyway integrate with many > existing password databases (RADIUS, LDAP, etc.) the way SSH and BEEP can, > I > would like to suggest removing text related to password authentication. > Also, I am looking for WG consensus on this issue. > > > > Best regards, > > Badra > > > On Thu, Aug 21, 2008 at 6:24 PM, Badra wrote: > >> Dear Pasi, >> >> Thank you very much for your comments and review. I totally agree with >> you >> regarding the password authentication and the first version of the >> document >> specification doesn't handle password-based authentication. >> >> But as you read on the mailing list discussion, people wants to keep ala >> unix authentication, which why the PSK derivation from password has been >> added to the document. But later they proposed to don nothing for the >> moment... >> I think the situation is clear especially after the AD comments, the best >> way is to remove any text related to password authentication. >> >> I will bring your comments to the mailing list to have a WG consensus on >> that. >> Thank you again. >> Best regards, >> Badra >> >> >> >> On Thu, Aug 21, 2008 at 11:12 AM, wrote: >> >>> Dear Badra, >>> >>> I've now read the threads from NETCONF mailing list in June/July/August, >>> minutes from IETF 72, and versions -02 and -03 of the NETCONF-over-TLS >>> document. >>> >>> After reading the mailing list, I did get the impression that many WG >>> member thought that password-based authentication is already handled >>> well enough by the existing NETCONF transports (SSH and BEEP), and the >>> NETCONF-over-TLS specification doesn't need to handle passwords. >>> >>> I would tend to agree with this view, and would recommend scoping >>> draft-ietf-netconf-tls to certificate-based authentication, which >>> isn't that well handled by the existing transports. I believe this >>> would be the main reason for using TLS -- especially considering that >>> NETCONF-over-TLS can't anyway integrate with many existing password >>> databases (RADIUS, LDAP, etc.) the way SSH and BEEP can. >>> >>> At least in SNMPv3, integrating with existing password databases has >>> been found to be very important, and that's why we have ISMS WG trying >>> to support that. NETCONF in the current RFCs got this part right, and >>> doing passwords the way proposed in current NETCONF-over-TLS draft >>> would IMHO be a step backwards. >>> >>> I'm also not very happy to see new cryptography in this specification >>> (the SHA-1 thing in Section 3.3). Although it's similar to what IKEv2 >>> does, that doesn't mean it would be a good idea for NETCONF -- and in >>> IKEv2, it's part of the IKEv2 itself; here it's something added >>> on top of RFC 4279 (BTW, something along those lines *was* proposed >>> when RFC 4279 was being done, but was rejected). >>> >>> Best regards, >>> Pasi >>> >>> > -----Original Message----- >>> > From: ext Badra [mailto:mbadra@gmail.com] >>> > Sent: 05 August, 2008 14:54 >>> > To: Eronen Pasi (Nokia-NRC/Helsinki); tim.polk@nist.gov >>> > Cc: Ersue Mehmet (NSN - DE/Muenich); ext Bert Wijnen (IETF); >>> > Mohamad Badra >>> > Subject: Re: NETCONF ovet TLS: Password issue >>> > >>> > Dear Tim and Pasi, >>> > >>> > During NETCONF session at Dublin meeting, there was a request from Tim >>> > to more explain why PSK computation from passwords is needed for the >>> > document "NETCONF over TLS". Please kindly comment on the following >>> > text and tell your recommendations. Many thanks. >>> > >>> > Best regards, >>> > Badra >>> > >>> > >>> > "NETCONF requires that its transport provide mutual authentication of >>> > client and server. Consequently, "NETCONF over TLS" reuses only those >>> > cipher suites that provide mutual authentication using certificates >>> > and/or PSK. In other words, anonymous cipher suites are forbidden with >>> > this document. >>> > >>> > On the certificate side: >>> > Both the client and the server MUST have a certificate to be sent >>> > during the Handshake phase. >>> > >>> > On the PSK side: >>> > In the first version of the document, it was expected to use RFC 4279 >>> > as it is and to apply section 5 of this RFC. However, and based on >>> > discussion on the NETCONF mailing list, people wants to keep using ala >>> > unix password/username. Consequently, the draft moved toward deriving >>> > the PSK from a couple of password/username. >>> > >>> > Note: the username is the psk_identity (in the RFC4279 terminology). >>> > >>> > In conformity with section 5.4 of RFC 4279, a management interface >>> > should be defined for entering the username (and the PSK). With the >>> > document, it consists of entering the username (psk_identity) and the >>> > password but the password isn't the PSK: both the username and the >>> > password are then used as inputs for the PSK derivation function as >>> > defined in the "NETCONF over TLS" document. The output value (20 >>> > bytes) of this function is the PSK. >>> > >>> > As you can see, this way of computing the PSK is specific to NETCONF >>> > and couldn't be used for other purpose. In addition, it doesn't >>> > require any modification, at least on the server side since this >>> > server stores directly the PSK (the result of the PSK derivation >>> > function)." >>> >> > > > -- > Badra > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 11:34:32 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B595E3A69A7; Thu, 21 Aug 2008 11:34:32 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94EE03A6A7A for ; Thu, 21 Aug 2008 11:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, 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 eHjuHCDzGnut for ; Thu, 21 Aug 2008 11:33:36 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id D1E283A69E0 for ; Thu, 21 Aug 2008 11:33:35 -0700 (PDT) Received: (qmail 41013 invoked from network); 21 Aug 2008 18:33:26 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 21 Aug 2008 18:33:26 -0000 Message-ID: From: "Bert Wijnen \(IETF\)" To: "netconf mailing list" Date: Thu, 21 Aug 2008 20:33:15 +0200 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: [Netconf] NETCONF ovet TLS changes proposed X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org WG members, The Security ADs have given their feedback on this document, see attached email from Pasi Eronen at the bottom. As a result, Badra wants to remove all text related to password. authetication. IT only makes sense that he does so if we have WG consensus on that. My personal feeling from the mailing list discussions and from the last session at IETF72 is that the WG indeed does agree with that removal. Please speak up before September 1st if you do not agree. Thanks, Bert Wijnen (sepaking as WG chair) ----- Original Message ----- From: "Badra" To: "Bert Wijnen (IETF)" ; "Ersue, Mehmet (NSN - DE/Muenich)" Sent: Thursday, August 21, 2008 6:43 PM Subject: NETCONF ovet TLS: Mail > Dear Bert, > > I would like to send the following text to the mailing list, but I prefer > that you of Mehmet do that since it includes a WG consensus request. > Please > advice. > > > Dear all, > > > > Pasi Eronen and Tim Polk (Security Ads) have revised the document during > the > last IETF session (see minutes) and via e-mail from Pasi (see below). > > > > Early versions of the document didn't specify the password-based > authentication and this later has been added to the document since some > members wanted ala unix authentication, which why PSK derivation from > passwords has been specified. > > > > Based on the comments from the Security ADs: the main reason for using > TLS; > especially considering that the document can't anyway integrate with many > existing password databases (RADIUS, LDAP, etc.) the way SSH and BEEP can, > I > would like to suggest removing text related to password authentication. > Also, I am looking for WG consensus on this issue. > > > > Best regards, > > Badra > > > On Thu, Aug 21, 2008 at 6:24 PM, Badra wrote: > >> Dear Pasi, >> >> Thank you very much for your comments and review. I totally agree with >> you >> regarding the password authentication and the first version of the >> document >> specification doesn't handle password-based authentication. >> >> But as you read on the mailing list discussion, people wants to keep ala >> unix authentication, which why the PSK derivation from password has been >> added to the document. But later they proposed to don nothing for the >> moment... >> I think the situation is clear especially after the AD comments, the best >> way is to remove any text related to password authentication. >> >> I will bring your comments to the mailing list to have a WG consensus on >> that. >> Thank you again. >> Best regards, >> Badra >> >> >> >> On Thu, Aug 21, 2008 at 11:12 AM, wrote: >> >>> Dear Badra, >>> >>> I've now read the threads from NETCONF mailing list in June/July/August, >>> minutes from IETF 72, and versions -02 and -03 of the NETCONF-over-TLS >>> document. >>> >>> After reading the mailing list, I did get the impression that many WG >>> member thought that password-based authentication is already handled >>> well enough by the existing NETCONF transports (SSH and BEEP), and the >>> NETCONF-over-TLS specification doesn't need to handle passwords. >>> >>> I would tend to agree with this view, and would recommend scoping >>> draft-ietf-netconf-tls to certificate-based authentication, which >>> isn't that well handled by the existing transports. I believe this >>> would be the main reason for using TLS -- especially considering that >>> NETCONF-over-TLS can't anyway integrate with many existing password >>> databases (RADIUS, LDAP, etc.) the way SSH and BEEP can. >>> >>> At least in SNMPv3, integrating with existing password databases has >>> been found to be very important, and that's why we have ISMS WG trying >>> to support that. NETCONF in the current RFCs got this part right, and >>> doing passwords the way proposed in current NETCONF-over-TLS draft >>> would IMHO be a step backwards. >>> >>> I'm also not very happy to see new cryptography in this specification >>> (the SHA-1 thing in Section 3.3). Although it's similar to what IKEv2 >>> does, that doesn't mean it would be a good idea for NETCONF -- and in >>> IKEv2, it's part of the IKEv2 itself; here it's something added >>> on top of RFC 4279 (BTW, something along those lines *was* proposed >>> when RFC 4279 was being done, but was rejected). >>> >>> Best regards, >>> Pasi >>> >>> > -----Original Message----- >>> > From: ext Badra [mailto:mbadra@gmail.com] >>> > Sent: 05 August, 2008 14:54 >>> > To: Eronen Pasi (Nokia-NRC/Helsinki); tim.polk@nist.gov >>> > Cc: Ersue Mehmet (NSN - DE/Muenich); ext Bert Wijnen (IETF); >>> > Mohamad Badra >>> > Subject: Re: NETCONF ovet TLS: Password issue >>> > >>> > Dear Tim and Pasi, >>> > >>> > During NETCONF session at Dublin meeting, there was a request from Tim >>> > to more explain why PSK computation from passwords is needed for the >>> > document "NETCONF over TLS". Please kindly comment on the following >>> > text and tell your recommendations. Many thanks. >>> > >>> > Best regards, >>> > Badra >>> > >>> > >>> > "NETCONF requires that its transport provide mutual authentication of >>> > client and server. Consequently, "NETCONF over TLS" reuses only those >>> > cipher suites that provide mutual authentication using certificates >>> > and/or PSK. In other words, anonymous cipher suites are forbidden with >>> > this document. >>> > >>> > On the certificate side: >>> > Both the client and the server MUST have a certificate to be sent >>> > during the Handshake phase. >>> > >>> > On the PSK side: >>> > In the first version of the document, it was expected to use RFC 4279 >>> > as it is and to apply section 5 of this RFC. However, and based on >>> > discussion on the NETCONF mailing list, people wants to keep using ala >>> > unix password/username. Consequently, the draft moved toward deriving >>> > the PSK from a couple of password/username. >>> > >>> > Note: the username is the psk_identity (in the RFC4279 terminology). >>> > >>> > In conformity with section 5.4 of RFC 4279, a management interface >>> > should be defined for entering the username (and the PSK). With the >>> > document, it consists of entering the username (psk_identity) and the >>> > password but the password isn't the PSK: both the username and the >>> > password are then used as inputs for the PSK derivation function as >>> > defined in the "NETCONF over TLS" document. The output value (20 >>> > bytes) of this function is the PSK. >>> > >>> > As you can see, this way of computing the PSK is specific to NETCONF >>> > and couldn't be used for other purpose. In addition, it doesn't >>> > require any modification, at least on the server side since this >>> > server stores directly the PSK (the result of the PSK derivation >>> > function)." >>> >> > > > -- > Badra > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 11:40:32 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 419873A6B75; Thu, 21 Aug 2008 11:40:32 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5EEC3A6AE1 for ; Thu, 21 Aug 2008 11:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDEoYjRhkHwD for ; Thu, 21 Aug 2008 11:14:00 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id F22613A6ABC for ; Thu, 21 Aug 2008 11:13:59 -0700 (PDT) Received: (qmail 97160 invoked from network); 21 Aug 2008 17:51:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 21 Aug 2008 17:51:49 -0000 X-YMail-OSG: DQfymC4VM1kU2Tuh8QvCqBcEPtXi3z7ntZ8aHzEDr7OdFKLl.84r7FG6CYjqGm3f5r0mO8oIxMdtI1LmKTYVCUbz5ziM.O4H0xk8ec7tsw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48ADAB33.7060401@andybierman.com> Date: Thu, 21 Aug 2008 10:51:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Andy Bierman , Balazs Lengyel , Andy Bierman , netconf mailing list References: <200808211421.m7LELiWt013742@idle.juniper.net> <48AD7ECE.7010406@ericsson.com> <48AD837D.5020408@netconfcentral.com> <20080821174106.GB21875@elstar.local> In-Reply-To: <20080821174106.GB21875@elstar.local> X-Mailman-Approved-At: Thu, 21 Aug 2008 11:40:31 -0700 Subject: Re: [Netconf] New work: 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > On Thu, Aug 21, 2008 at 08:02:21AM -0700, Andy Bierman wrote: > >> 3) with-defaults-default leaf in netconf-state DM (or separate DM?) >> - is this read-only or just min-access read-only? >> - should this be required (read-only) even if with-defaults >> capability not supported? > > Why is this needed? > So the manager will know what to expect when it issues a 'plain' request without the flag. Since RFC 4741 is silent on the issue, it seems like it should be a vendor-configured property. Perhaps not every application of NETCONF will be 90% defaults. Perhaps returning defaults will not be perceived as a total waste of time by the application developer. Another NETCONF Axiom: Axiom 3: A NETCONF manager should always be able to determine if an agent feature is supported, without relying on 'try it and see what happens'. SNMP experience has proven this method to be unreliable. > /js > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 11:40:32 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 419873A6B75; Thu, 21 Aug 2008 11:40:32 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5EEC3A6AE1 for ; Thu, 21 Aug 2008 11:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDEoYjRhkHwD for ; Thu, 21 Aug 2008 11:14:00 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id F22613A6ABC for ; Thu, 21 Aug 2008 11:13:59 -0700 (PDT) Received: (qmail 97160 invoked from network); 21 Aug 2008 17:51:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 21 Aug 2008 17:51:49 -0000 X-YMail-OSG: DQfymC4VM1kU2Tuh8QvCqBcEPtXi3z7ntZ8aHzEDr7OdFKLl.84r7FG6CYjqGm3f5r0mO8oIxMdtI1LmKTYVCUbz5ziM.O4H0xk8ec7tsw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48ADAB33.7060401@andybierman.com> Date: Thu, 21 Aug 2008 10:51:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Andy Bierman , Balazs Lengyel , Andy Bierman , netconf mailing list References: <200808211421.m7LELiWt013742@idle.juniper.net> <48AD7ECE.7010406@ericsson.com> <48AD837D.5020408@netconfcentral.com> <20080821174106.GB21875@elstar.local> In-Reply-To: <20080821174106.GB21875@elstar.local> X-Mailman-Approved-At: Thu, 21 Aug 2008 11:40:31 -0700 Subject: Re: [Netconf] New work: 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > On Thu, Aug 21, 2008 at 08:02:21AM -0700, Andy Bierman wrote: > >> 3) with-defaults-default leaf in netconf-state DM (or separate DM?) >> - is this read-only or just min-access read-only? >> - should this be required (read-only) even if with-defaults >> capability not supported? > > Why is this needed? > So the manager will know what to expect when it issues a 'plain' request without the flag. Since RFC 4741 is silent on the issue, it seems like it should be a vendor-configured property. Perhaps not every application of NETCONF will be 90% defaults. Perhaps returning defaults will not be perceived as a total waste of time by the application developer. Another NETCONF Axiom: Axiom 3: A NETCONF manager should always be able to determine if an agent feature is supported, without relying on 'try it and see what happens'. SNMP experience has proven this method to be unreliable. > /js > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 11:53:05 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E10C3A6B6A; Thu, 21 Aug 2008 11:53:05 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D340B3A6B6A for ; Thu, 21 Aug 2008 11:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.261, 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 9Fcc7pGYGz2G for ; Thu, 21 Aug 2008 11:40:30 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 1807B3A6A31 for ; Thu, 21 Aug 2008 11:40:29 -0700 (PDT) Received: (qmail 44527 invoked from network); 21 Aug 2008 18:39:50 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 21 Aug 2008 18:39:50 -0000 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Andy Bierman" , "Martin Bjorklund" References: <200808111537.m7BFbSS2098789@idle.juniper.net> <48A060AC.70203@netconfcentral.com><20080811.203257.128375678.mbj@tail-f.com> <48ADA7DE.3030108@netconfcentral.com> In-Reply-To: <48ADA7DE.3030108@netconfcentral.com> Date: Thu, 21 Aug 2008 20:39:30 +0200 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org May I ask that someone writes up proposed clarification text with instructions as to where it would have to go into RFC4741, so that we can all see exactly what the "fix" would look like and the can then all cast our opinion on it? Thanks, Bert Wijnen (speaking as WG co-chair) ----- Original Message ----- From: "Andy Bierman" To: "Martin Bjorklund" Cc: Sent: Thursday, August 21, 2008 7:37 PM Subject: Re: [Netconf] rpc-reply > Martin Bjorklund wrote: >> Hi, >> >> I asked this question to the netconf WG but it of course impacts what >> will be done in netmod. Going back to my original question: >> >> Section 4.2 of rfc4741 says: >> >> The response name and response data are encoded as the contents of >> the element. The name of the reply is an element >> directly inside the element, and any data is encoded >> inside this element. >> >> Does the WG think that this text is correct, and the XSD wrong? >> >> If so, should I interpret "the reply is an element" as saying that >> there can be *one* reply and never more? For example, is this >> illegal: >> >> >> >> 10.1.2.3 >> >> >> >> 10.1.2.3 >> 10.1.2.3 >> 56 >> >> 5 >> 0 >> 100 >> >> no response >> >> >> > > Any chance of a resolution on this detail? > If the XSD is normative, then YANG rpc output statements > may only contain 1 element which gets inserted > as a child node of the NETCONF 1.0 'data' element. > > If the XSD is wrong, then the YANG output statement > may contain more than 1 element, with any name, > and any namespace, which are child nodes of > the element. > > I agree with Phil's interpretation, i.e., that the > XSD applies to the RPC methods defined in RFC 4741, > and not every possible RPC method, especially those in vendor namespaces. > > The results from the example above would actually look more like this: > > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns="http://example.com/ns/ping"> > 10.1.2.3 > 10.1.2.3 > 56 > > 5 > 0 > 100 > > no response > > > > IMO, this should be allowed. > The only rule would be that all instances > must be encoded before any data nodes (as it is now). > > It really wouldn't affect a vendor's deployed agents, > since all the 'official' RPCs would also be valid > with this clarified interpretation. > > >> >> >> /martin >> >> >> > > > Andy > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 11:53:05 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E10C3A6B6A; Thu, 21 Aug 2008 11:53:05 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D340B3A6B6A for ; Thu, 21 Aug 2008 11:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.261, 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 9Fcc7pGYGz2G for ; Thu, 21 Aug 2008 11:40:30 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 1807B3A6A31 for ; Thu, 21 Aug 2008 11:40:29 -0700 (PDT) Received: (qmail 44527 invoked from network); 21 Aug 2008 18:39:50 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 21 Aug 2008 18:39:50 -0000 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Andy Bierman" , "Martin Bjorklund" References: <200808111537.m7BFbSS2098789@idle.juniper.net> <48A060AC.70203@netconfcentral.com><20080811.203257.128375678.mbj@tail-f.com> <48ADA7DE.3030108@netconfcentral.com> In-Reply-To: <48ADA7DE.3030108@netconfcentral.com> Date: Thu, 21 Aug 2008 20:39:30 +0200 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org May I ask that someone writes up proposed clarification text with instructions as to where it would have to go into RFC4741, so that we can all see exactly what the "fix" would look like and the can then all cast our opinion on it? Thanks, Bert Wijnen (speaking as WG co-chair) ----- Original Message ----- From: "Andy Bierman" To: "Martin Bjorklund" Cc: Sent: Thursday, August 21, 2008 7:37 PM Subject: Re: [Netconf] rpc-reply > Martin Bjorklund wrote: >> Hi, >> >> I asked this question to the netconf WG but it of course impacts what >> will be done in netmod. Going back to my original question: >> >> Section 4.2 of rfc4741 says: >> >> The response name and response data are encoded as the contents of >> the element. The name of the reply is an element >> directly inside the element, and any data is encoded >> inside this element. >> >> Does the WG think that this text is correct, and the XSD wrong? >> >> If so, should I interpret "the reply is an element" as saying that >> there can be *one* reply and never more? For example, is this >> illegal: >> >> >> >> 10.1.2.3 >> >> >> >> 10.1.2.3 >> 10.1.2.3 >> 56 >> >> 5 >> 0 >> 100 >> >> no response >> >> >> > > Any chance of a resolution on this detail? > If the XSD is normative, then YANG rpc output statements > may only contain 1 element which gets inserted > as a child node of the NETCONF 1.0 'data' element. > > If the XSD is wrong, then the YANG output statement > may contain more than 1 element, with any name, > and any namespace, which are child nodes of > the element. > > I agree with Phil's interpretation, i.e., that the > XSD applies to the RPC methods defined in RFC 4741, > and not every possible RPC method, especially those in vendor namespaces. > > The results from the example above would actually look more like this: > > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns="http://example.com/ns/ping"> > 10.1.2.3 > 10.1.2.3 > 56 > > 5 > 0 > 100 > > no response > > > > IMO, this should be allowed. > The only rule would be that all instances > must be encoded before any data nodes (as it is now). > > It really wouldn't affect a vendor's deployed agents, > since all the 'official' RPCs would also be valid > with this clarified interpretation. > > >> >> >> /martin >> >> >> > > > Andy > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 13:49:56 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ED183A698B; Thu, 21 Aug 2008 13:49:56 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2FB53A6B35 for ; Thu, 21 Aug 2008 13:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.462 X-Spam-Level: X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[AWL=0.787, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xETIqHFOt-0b for ; Thu, 21 Aug 2008 13:43: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 712023A685F for ; Thu, 21 Aug 2008 13:43:39 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F3C12C00AB; Thu, 21 Aug 2008 22:42:27 +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 PZVMcqcdLsLA; Thu, 21 Aug 2008 22:42:21 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2EB45C00A8; Thu, 21 Aug 2008 22:42:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5500069A6FB; Thu, 21 Aug 2008 22:42:20 +0200 (CEST) Date: Thu, 21 Aug 2008 22:42:20 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080821204220.GA22007@elstar.local> Mail-Followup-To: Andy Bierman , Andy Bierman , Balazs Lengyel , netconf mailing list References: <200808211421.m7LELiWt013742@idle.juniper.net> <48AD7ECE.7010406@ericsson.com> <48AD837D.5020408@netconfcentral.com> <20080821174106.GB21875@elstar.local> <48ADAB33.7060401@andybierman.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48ADAB33.7060401@andybierman.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf mailing list Subject: Re: [Netconf] New work: with-defaults X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Thu, Aug 21, 2008 at 10:51:47AM -0700, Andy Bierman wrote: > Juergen Schoenwaelder wrote: >> On Thu, Aug 21, 2008 at 08:02:21AM -0700, Andy Bierman wrote: >> >>> 3) with-defaults-default leaf in netconf-state DM (or separate DM?) >>> - is this read-only or just min-access read-only? >>> - should this be required (read-only) even if with-defaults >>> capability not supported? >> >> Why is this needed? >> > > So the manager will know what to expect when it issues > a 'plain' request without the flag. Since RFC 4741 is > silent on the issue, it seems like it should be a From netconf-bounces@ietf.org Thu Aug 21 13:49:56 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ED183A698B; Thu, 21 Aug 2008 13:49:56 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2FB53A6B35 for ; Thu, 21 Aug 2008 13:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.462 X-Spam-Level: X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[AWL=0.787, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xETIqHFOt-0b for ; Thu, 21 Aug 2008 13:43: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 712023A685F for ; Thu, 21 Aug 2008 13:43:39 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F3C12C00AB; Thu, 21 Aug 2008 22:42:27 +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 PZVMcqcdLsLA; Thu, 21 Aug 2008 22:42:21 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2EB45C00A8; Thu, 21 Aug 2008 22:42:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5500069A6FB; Thu, 21 Aug 2008 22:42:20 +0200 (CEST) Date: Thu, 21 Aug 2008 22:42:20 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20080821204220.GA22007@elstar.local> Mail-Followup-To: Andy Bierman , Andy Bierman , Balazs Lengyel , netconf mailing list References: <200808211421.m7LELiWt013742@idle.juniper.net> <48AD7ECE.7010406@ericsson.com> <48AD837D.5020408@netconfcentral.com> <20080821174106.GB21875@elstar.local> <48ADAB33.7060401@andybierman.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48ADAB33.7060401@andybierman.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf mailing list Subject: Re: [Netconf] New work: with-defaults X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Thu, Aug 21, 2008 at 10:51:47AM -0700, Andy Bierman wrote: > Juergen Schoenwaelder wrote: >> On Thu, Aug 21, 2008 at 08:02:21AM -0700, Andy Bierman wrote: >> >>> 3) with-defaults-default leaf in netconf-state DM (or separate DM?) >>> - is this read-only or just min-access read-only? >>> - should this be required (read-only) even if with-defaults >>> capability not supported? >> >> Why is this needed? >> > > So the manager will know what to expect when it issues > a 'plain' request without the flag. Since RFC 4741 is > silent on the issue, it seems like it should be a > vend> vendor-configured property. Can we not clarify RFC 4741 and by announcing the with-defaults capability we are done? I do not really like to read various leafs before I know what a get-config really does... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf or-configured property. Can we not clarify RFC 4741 and by announcing the with-defaults capability we are done? I do not really like to read various leafs before I know what a get-config really does... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 13:55:06 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEF3B3A698B; Thu, 21 Aug 2008 13:55:05 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B85F528C0E1 for ; Thu, 21 Aug 2008 13:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.158, 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 1KnYKZVDGKVl for ; Thu, 21 Aug 2008 13:52:29 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 0FE363A6AEA for ; Thu, 21 Aug 2008 13:52:29 -0700 (PDT) Received: (qmail 1326 invoked from network); 21 Aug 2008 20:51:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 21 Aug 2008 20:51:36 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48ADD556.1040209@netconfcentral.com> Date: Thu, 21 Aug 2008 13:51:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Balazs Lengyel , netconf mailing list References: <200808211421.m7LELiWt013742@idle.juniper.net> <48AD7ECE.7010406@ericsson.com> <48AD837D.5020408@netconfcentral.com> <20080821174106.GB21875@elstar.local> <48ADAB33.7060401@andybierman.com> <20080821204220.GA22007@elstar.local> In-Reply-To: <20080821204220.GA22007@elstar.local> Subject: Re: [Netconf] New work: 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > On Thu, Aug 21, 2008 at 10:51:47AM -0700, Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Thu, Aug 21, 2008 at 08:02:21AM -0700, Andy Bierman wrote: >>> >>>> 3) with-defaults-default leaf in netconf-state DM (or separate DM?) >>>> - is this read-only or just min-access read-only? >>>> - should this be required (read-only) even if with-defaults >>>> capability not supported? >>> Why is this needed? >>> >> So the manager will know what to expect when it issues >> a 'plain' request without the flag. Since RFC 4741 is >> silent on the issue, it seems like it should be a >> vendor-configured property. > > Can we not clarify RFC 4741 and by announcing the with-defaults > capability we are done? I do not really like to read various leafs > before I know what a get-config really does... > Excellent idea. Something like: urn:ietf:params:netconf:capability:with-defaults?default=false [This agent will not return defaults unless asked for them.] Another detail: this capability does not differentiate between a value set by the manager or the agent. If the default is '3' and the value is '3', it is considered to contain the default, regardless of how it was created. > /js > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 21 13:55:06 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEF3B3A698B; Thu, 21 Aug 2008 13:55:05 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B85F528C0E1 for ; Thu, 21 Aug 2008 13:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.158, 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 1KnYKZVDGKVl for ; Thu, 21 Aug 2008 13:52:29 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 0FE363A6AEA for ; Thu, 21 Aug 2008 13:52:29 -0700 (PDT) Received: (qmail 1326 invoked from network); 21 Aug 2008 20:51:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 21 Aug 2008 20:51:36 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48ADD556.1040209@netconfcentral.com> Date: Thu, 21 Aug 2008 13:51:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Balazs Lengyel , netconf mailing list References: <200808211421.m7LELiWt013742@idle.juniper.net> <48AD7ECE.7010406@ericsson.com> <48AD837D.5020408@netconfcentral.com> <20080821174106.GB21875@elstar.local> <48ADAB33.7060401@andybierman.com> <20080821204220.GA22007@elstar.local> In-Reply-To: <20080821204220.GA22007@elstar.local> Subject: Re: [Netconf] New work: 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > On Thu, Aug 21, 2008 at 10:51:47AM -0700, Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Thu, Aug 21, 2008 at 08:02:21AM -0700, Andy Bierman wrote: >>> >>>> 3) with-defaults-default leaf in netconf-state DM (or separate DM?) >>>> - is this read-only or just min-access read-only? >>>> - should this be required (read-only) even if with-defaults >>>> capability not supported? >>> Why is this needed? >>> >> So the manager will know what to expect when it issues >> a 'plain' request without the flag. Since RFC 4741 is >> silent on the issue, it seems like it should be a >> vendor-configured property. > > Can we not clarify RFC 4741 and by announcing the with-defaults > capability we are done? I do not really like to read various leafs > before I know what a get-config really does... > Excellent idea. Something like: urn:ietf:params:netconf:capability:with-defaults?default=false [This agent will not return defaults unless asked for them.] Another detail: this capability does not differentiate between a value set by the manager or the agent. If the default is '3' and the value is '3', it is considered to contain the default, regardless of how it was created. > /js > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 22 06:07:40 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36FE93A6B9C; Fri, 22 Aug 2008 06:07:40 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDEAB28C2B0 for ; Fri, 22 Aug 2008 05:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 mCuGAdBflSBI for ; Fri, 22 Aug 2008 05:57:56 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 00CAF28C322 for ; Fri, 22 Aug 2008 05:57:55 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Fri, 22 Aug 2008 05:57:36 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Aug 2008 05:56:45 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Aug 2008 05:56:45 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 05:56:51 -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 m7MCuiu18604; Fri, 22 Aug 2008 05:56:44 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7MCrEnx027668; Fri, 22 Aug 2008 12:53:15 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808221253.m7MCrEnx027668@idle.juniper.net> To: Andy Bierman In-reply-to: <48ADD556.1040209@netconfcentral.com> Date: Fri, 22 Aug 2008 08:53:14 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Aug 2008 12:56:51.0907 (UTC) FILETIME=[8BFCD130:01C90456] Cc: netconf mailing list Subject: Re: [Netconf] New work: 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >Another detail: this capability does not differentiate >between a value set by the manager or the agent. If >the default is '3' and the value is '3', it is considered >to contain the default, regardless of how it was created. This is another can o' worms. I preserve user specified values even when the value matches the default. This allows users complete control over what appears in their config. Values to not disappear simply because the match the default. If you want this behavior, I'd suggest making your "with-defaults" a tri-state value: "all" -- report all default values "trim" -- do not report values if they match the default "explicit" -- report any values explicitly set Thanks, Phil _______________________________________________ NetconfFrom netconf-bounces@ietf.org Fri Aug 22 06:07:40 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36FE93A6B9C; Fri, 22 Aug 2008 06:07:40 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDEAB28C2B0 for ; Fri, 22 Aug 2008 05:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 mCuGAdBflSBI for ; Fri, 22 Aug 2008 05:57:56 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 00CAF28C322 for ; Fri, 22 Aug 2008 05:57:55 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Fri, 22 Aug 2008 05:57:36 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Aug 2008 05:56:45 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Aug 2008 05:56:45 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 05:56:51 -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 m7MCuiu18604; Fri, 22 Aug 2008 05:56:44 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7MCrEnx027668; Fri, 22 Aug 2008 12:53:15 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808221253.m7MCrEnx027668@idle.juniper.net> To: Andy Bierman In-reply-to: <48ADD556.1040209@netconfcentral.com> Date: Fri, 22 Aug 2008 08:53:14 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Aug 2008 12:56:51.0907 (UTC) FILETIME=[8BFCD130:01C90456] Cc: netconf mailing list Subject: Re: [Netconf] New work: 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >Another detail: this capability does not differentiate >between a value set by the manager or the agent. If >the default is '3' and the value is '3', it is considered >to contain the default, regardless of how it was created. This is another can o' worms. I preserve user specified values even when the value matches the default. This allows users complete control over what appears in their config. Values to not disappear simply because the match the default. If you want this behavior, I'd suggest making your "with-defaults" a tri-state value: "all" -- report all default values "trim" -- do not report values if they match the default "explicit" -- report any values explicitly set Thanks, Phil _______________________________________________ Netconf maili mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ng list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 22 12:05:42 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 323E83A6ABD; Fri, 22 Aug 2008 12:05:42 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0549428C180 for ; Fri, 22 Aug 2008 12:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.866 X-Spam-Level: X-Spam-Status: No, score=-0.866 tagged_above=-999 required=5 tests=[AWL=-0.867, 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 O6i6+nH0Vddi for ; Fri, 22 Aug 2008 12:05:37 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 2CDBE3A6ABD for ; Fri, 22 Aug 2008 12:05:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=G44Ez16xxUvghaVE895owr+S+SCiLIJx66VkEGtYSMk/jYuYob1kQplRg080eqVA; 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 [68.164.84.32] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KWbwJ-00007A-7K for netconf@ietf.org; Fri, 22 Aug 2008 15:04:51 -0400 Message-ID: <002c01c9048a$23746b80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "netconf mailing list" References: <200808221253.m7MCrEnx027668@idle.juniper.net> Date: Fri, 22 Aug 2008 12:06:08 -0700 MIME-Version: 1.0 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3bc2196c4d30f37aca5fd2dd310e90ef2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.84.32 Subject: Re: [Netconf] New work: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi - > From: "Phil Shafer" > To: "Andy Bierman" > Cc: "netconf mailing list" > Sent: Friday, August 22, 2008 5:53 AM > Subject: Re: [Netconf] New work: with-defaults > > Andy Bierman writes: > >Another detail: this capability does not differentiate > >between a value set by the manager or the agent. If > >the default is '3' and the value is '3', it is considered > >to contain the default, regardless of how it was created. > > This is another can o' worms. I preserve user specified values > even when the value matches the default. This allows users complete > control over what appears in their config. Values to not disappear > simply because the match the default. This seems surprising if the point of having defaults was to avoid the need to shovel those values back and forth. If default values are part of the interface contract between client and server, then how something came to have a value equal to the default shouldn't be a factor. Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 22 12:05:42 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 323E83A6ABD; Fri, 22 Aug 2008 12:05:42 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0549428C180 for ; Fri, 22 Aug 2008 12:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.866 X-Spam-Level: X-Spam-Status: No, score=-0.866 tagged_above=-999 required=5 tests=[AWL=-0.867, 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 O6i6+nH0Vddi for ; Fri, 22 Aug 2008 12:05:37 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 2CDBE3A6ABD for ; Fri, 22 Aug 2008 12:05:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=G44Ez16xxUvghaVE895owr+S+SCiLIJx66VkEGtYSMk/jYuYob1kQplRg080eqVA; 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 [68.164.84.32] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KWbwJ-00007A-7K for netconf@ietf.org; Fri, 22 Aug 2008 15:04:51 -0400 Message-ID: <002c01c9048a$23746b80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "netconf mailing list" References: <200808221253.m7MCrEnx027668@idle.juniper.net> Date: Fri, 22 Aug 2008 12:06:08 -0700 MIME-Version: 1.0 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3bc2196c4d30f37aca5fd2dd310e90ef2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.84.32 Subject: Re: [Netconf] New work: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi - > From: "Phil Shafer" > To: "Andy Bierman" > Cc: "netconf mailing list" > Sent: Friday, August 22, 2008 5:53 AM > Subject: Re: [Netconf] New work: with-defaults > > Andy Bierman writes: > >Another detail: this capability does not differentiate > >between a value set by the manager or the agent. If > >the default is '3' and the value is '3', it is considered > >to contain the default, regardless of how it was created. > > This is another can o' worms. I preserve user specified values > even when the value matches the default. This allows users complete > control over what appears in their config. Values to not disappear > simply because the match the default. This seems surprising if the point of having defaults was to avoid the need to shovel those values back and forth. If default values are part of the interface contract between client and server, then how something came to have a value equal to the default shouldn't be a factor. Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 22 12:30:01 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D209528C16C; Fri, 22 Aug 2008 12:30:01 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAC9F28C16C for ; Fri, 22 Aug 2008 12:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 EElL-SHxLDUN for ; Fri, 22 Aug 2008 12:30:00 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id A090B28C11A for ; Fri, 22 Aug 2008 12:29:59 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Fri, 22 Aug 2008 12:29:18 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Aug 2008 12:29:16 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Aug 2008 12:29:16 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 12:29: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 m7MJTFu95482; Fri, 22 Aug 2008 12:29:15 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7MJPjDp031133; Fri, 22 Aug 2008 19:25:45 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808221925.m7MJPjDp031133@idle.juniper.net> To: "Randy Presuhn" In-reply-to: <002c01c9048a$23746b80$6801a8c0@oemcomputer> Date: Fri, 22 Aug 2008 15:25:45 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Aug 2008 19:29:15.0924 (UTC) FILETIME=[5D50B540:01C9048D] Cc: netconf mailing list Subject: Re: [Netconf] New work: 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Randy Presuhn" writes: >This seems surprising if the point of having defaults was to avoid the >need to shovel those values back and forth. If default values are part >of the interface contract between client and server, then how something >came to have a value equal to the default shouldn't be a factor. Many of my customers like to say "set mtu 1500" even though they know it's the default. They like to explicitly set it and see it. I personally find it odd when I explicitly set something, come back later and find it gone. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 22 12:30:01 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D209528C16C; Fri, 22 Aug 2008 12:30:01 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAC9F28C16C for ; Fri, 22 Aug 2008 12:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 EElL-SHxLDUN for ; Fri, 22 Aug 2008 12:30:00 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id A090B28C11A for ; Fri, 22 Aug 2008 12:29:59 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Fri, 22 Aug 2008 12:29:18 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Aug 2008 12:29:16 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Aug 2008 12:29:16 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 12:29: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 m7MJTFu95482; Fri, 22 Aug 2008 12:29:15 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7MJPjDp031133; Fri, 22 Aug 2008 19:25:45 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808221925.m7MJPjDp031133@idle.juniper.net> To: "Randy Presuhn" In-reply-to: <002c01c9048a$23746b80$6801a8c0@oemcomputer> Date: Fri, 22 Aug 2008 15:25:45 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Aug 2008 19:29:15.0924 (UTC) FILETIME=[5D50B540:01C9048D] Cc: netconf mailing list Subject: Re: [Netconf] New work: 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Randy Presuhn" writes: >This seems surprising if the point of having defaults was to avoid the >need to shovel those values back and forth. If default values are part >of the interface contract between client and server, then how something >came to have a value equal to the default shouldn't be a factor. Many of my customers like to say "set mtu 1500" even though they know it's the default. They like to explicitly set it and see it. I personally find it odd when I explicitly set something, come back later and find it gone. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 22 15:29:31 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17CDE3A6A5A; Fri, 22 Aug 2008 15:29:31 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 075273A6935 for ; Fri, 22 Aug 2008 15:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.129, 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 my8CvPvSa39a for ; Fri, 22 Aug 2008 15:29:29 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 54BBF3A6A5A for ; Fri, 22 Aug 2008 15:29:29 -0700 (PDT) Received: (qmail 20846 invoked from network); 22 Aug 2008 22:29:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 22 Aug 2008 22:29:37 -0000 X-YMail-OSG: trsd5cMVM1l1ahUoEo6nh6BkE9vdglFFFA4zFNUByWH4MG6FAgmqCinUuMC0irm_yWzg5AmIZrkL1z5Itm6d8qj25EkxHgJ5CoruABXFOQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AF3DD0.7010800@netconfcentral.com> Date: Fri, 22 Aug 2008 15:29:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808202134.m7KLYLOZ003375@idle.juniper.net> In-Reply-To: <200808202134.m7KLYLOZ003375@idle.juniper.net> Cc: NETCONF Subject: Re: [Netconf] continue-on-error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> But first, does anybody implement continue-on-error, >> and if so, what does it really mean in your agent? > > "continue-on-error" means "do your best to keep going". > "your best" can't be defined easily, since you're > facing input that contains errors. > pretty vague. I used to think it meant there are no errors detected in syntax or constraints, but if an error occurred trying to apply the (e.g., malloc failed), then try to continue. Clearly this is the intent if test-option 'test-then-set' is true. (It actually requires more -- a must succeed too.) But for my internal operation, using the same infrastructure as , I want to skip over syntax errors in one subtree if another subtree is good. You are suggesting that even for , skipping over invalid well-formed XML is OK for 'continue-on-error'. Seems fine to me, since the spec doesn't really say. > Thanks, > Phil > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 22 15:29:31 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17CDE3A6A5A; Fri, 22 Aug 2008 15:29:31 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 075273A6935 for ; Fri, 22 Aug 2008 15:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.129, 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 my8CvPvSa39a for ; Fri, 22 Aug 2008 15:29:29 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 54BBF3A6A5A for ; Fri, 22 Aug 2008 15:29:29 -0700 (PDT) Received: (qmail 20846 invoked from network); 22 Aug 2008 22:29:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 22 Aug 2008 22:29:37 -0000 X-YMail-OSG: trsd5cMVM1l1ahUoEo6nh6BkE9vdglFFFA4zFNUByWH4MG6FAgmqCinUuMC0irm_yWzg5AmIZrkL1z5Itm6d8qj25EkxHgJ5CoruABXFOQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AF3DD0.7010800@netconfcentral.com> Date: Fri, 22 Aug 2008 15:29:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808202134.m7KLYLOZ003375@idle.juniper.net> In-Reply-To: <200808202134.m7KLYLOZ003375@idle.juniper.net> Cc: NETCONF Subject: Re: [Netconf] continue-on-error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> But first, does anybody implement continue-on-error, >> and if so, what does it really mean in your agent? > > "continue-on-error" means "do your best to keep going". > "your best" can't be defined easily, since you're > facing input that contains errors. > pretty vague. I used to think it meant there are no errors detected in syntax or constraints, but if an error occurred trying to apply the (e.g., malloc failed), then try to continue. Clearly this is the intent if test-option 'test-then-set' is true. (It actually requires more -- a must succeed too.) But for my internal operation, using the same infrastructure as , I want to skip over syntax errors in one subtree if another subtree is good. You are suggesting that even for , skipping over invalid well-formed XML is OK for 'continue-on-error'. Seems fine to me, since the spec doesn't really say. > Thanks, > Phil > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 22 15:39:28 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 317AA3A6ACD; Fri, 22 Aug 2008 15:39:28 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF2DF3A6AC3 for ; Fri, 22 Aug 2008 15:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZliENkxUVoh for ; Fri, 22 Aug 2008 15:39:26 -0700 (PDT) Received: from diotima.switch.ch (diotima.switch.ch [IPv6:2001:620:0:4:203:baff:fe4c:d751]) by core3.amsl.com (Postfix) with ESMTP id 502E93A6A9E for ; Fri, 22 Aug 2008 15:39:24 -0700 (PDT) Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.14.3+Sun/8.14.3) with ESMTP id m7MMdTrq013816; Sat, 23 Aug 2008 00:39:29 +0200 (CEST) Received: (from leinen@localhost) by diotima.switch.ch (8.14.3+Sun/8.14.3/Submit) id m7MMdSWf013815; Sat, 23 Aug 2008 00:39:28 +0200 (CEST) X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon.leinen@switch.ch using -f From: Simon Leinen To: Phil Shafer In-Reply-To: <200808221925.m7MJPjDp031133@idle.juniper.net> (Phil Shafer's message of "Fri, 22 Aug 2008 15:25:45 -0400") References: <200808221925.m7MJPjDp031133@idle.juniper.net> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` Date: Sat, 23 Aug 2008 00:39:28 +0200 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.2 (usg-unix-v) MIME-Version: 1.0 Cc: netconf mailing list Subject: Re: [Netconf] New work: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer writes: > "Randy Presuhn" writes: >> This seems surprising if the point of having defaults was to avoid >> the need to shovel those values back and forth. If default values >> are part of the interface contract between client and server, then >> how something came to have a value equal to the default shouldn't >> be a factor. > Many of my customers like to say "set mtu 1500" even though they > know it's the default. They like to explicitly set it and see it. Thanks for bringing up the MTU example. This reminds me of why I strongly agree with Phil here: It is important to distinguish between an unset parameter and a parameter that has been explicitly configured to a value that happens to match the default. Here's a true story from an operator: There's a brand of router we and many other people use. When configuring a tunnel interface, the configuration default for the MTU is derived from the MTU of the interface towards the remote endpoint. Operationally, it is usually required to have equal MTU sizes on both ends of the tunnel (different routers, possibly under different administration), so we have to agree on one value. Now let's say that, on my router, and at the time the configuration is entered, the agreed-upon value happens to be the same as the default MTU - depending on which interface the route to the other endpoint points to at that time. Because the router works according to what Randy finds natural, as opposed to what Phil and I prefer, it will simply ignore my configuration because it matches the default. This will work just fine... until my router is rebooted for some reason. The configuration (with the MTU set to "default") is re-interpreted in a different context, where the route to the other endpoint may point to a different interface with a different MTU. The result will be that the tunnel MTU is now set to some other value, which leads to the tunnel blackholing large packets in one direction. I have seen this happen to me, and I have heard others had the same issue. Believe me that debugging these kinds of problems is NOT FUN. You may say that this wouldn't be a problem if the default MTU in this case wasn't derived from operational state, and I sort-of agree. But the people who wrote the software probably have good (probably usability) arguments for doing it that way. > I personally find it odd when I explicitly set something, come back > later and find it gone. Precisely. -- Simon. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 22 15:39:28 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 317AA3A6ACD; Fri, 22 Aug 2008 15:39:28 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF2DF3A6AC3 for ; Fri, 22 Aug 2008 15:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZliENkxUVoh for ; Fri, 22 Aug 2008 15:39:26 -0700 (PDT) Received: from diotima.switch.ch (diotima.switch.ch [IPv6:2001:620:0:4:203:baff:fe4c:d751]) by core3.amsl.com (Postfix) with ESMTP id 502E93A6A9E for ; Fri, 22 Aug 2008 15:39:24 -0700 (PDT) Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.14.3+Sun/8.14.3) with ESMTP id m7MMdTrq013816; Sat, 23 Aug 2008 00:39:29 +0200 (CEST) Received: (from leinen@localhost) by diotima.switch.ch (8.14.3+Sun/8.14.3/Submit) id m7MMdSWf013815; Sat, 23 Aug 2008 00:39:28 +0200 (CEST) X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon.leinen@switch.ch using -f From: Simon Leinen To: Phil Shafer In-Reply-To: <200808221925.m7MJPjDp031133@idle.juniper.net> (Phil Shafer's message of "Fri, 22 Aug 2008 15:25:45 -0400") References: <200808221925.m7MJPjDp031133@idle.juniper.net> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` Date: Sat, 23 Aug 2008 00:39:28 +0200 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.2 (usg-unix-v) MIME-Version: 1.0 Cc: netconf mailing list Subject: Re: [Netconf] New work: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer writes: > "Randy Presuhn" writes: >> This seems surprising if the point of having defaults was to avoid >> the need to shovel those values back and forth. If default values >> are part of the interface contract between client and server, then >> how something came to have a value equal to the default shouldn't >> be a factor. > Many of my customers like to say "set mtu 1500" even though they > know it's the default. They like to explicitly set it and see it. Thanks for bringing up the MTU example. This reminds me of why I strongly agree with Phil here: It is important to distinguish between an unset parameter and a parameter that has been explicitly configured to a value that happens to match the default. Here's a true story from an operator: There's a brand of router we and many other people use. When configuring a tunnel interface, the configuration default for the MTU is derived from the MTU of the interface towards the remote endpoint. Operationally, it is usually required to have equal MTU sizes on both ends of the tunnel (different routers, possibly under different administration), so we have to agree on one value. Now let's say that, on my router, and at the time the configuration is entered, the agreed-upon value happens to be the same as the default MTU - depending on which interface the route to the other endpoint points to at that time. Because the router works according to what Randy finds natural, as opposed to what Phil and I prefer, it will simply ignore my configuration because it matches the default. This will work just fine... until my router is rebooted for some reason. The configuration (with the MTU set to "default") is re-interpreted in a different context, where the route to the other endpoint may point to a different interface with a different MTU. The result will be that the tunnel MTU is now set to some other value, which leads to the tunnel blackholing large packets in one direction. I have seen this happen to me, and I have heard others had the same issue. Believe me that debugging these kinds of problems is NOT FUN. You may say that this wouldn't be a problem if the default MTU in this case wasn't derived from operational state, and I sort-of agree. But the people who wrote the software probably have good (probably usability) arguments for doing it that way. > I personally find it odd when I explicitly set something, come back > later and find it gone. Precisely. -- Simon. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 22 15:52:45 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57C493A6A29; Fri, 22 Aug 2008 15:52:45 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11D773A6A29 for ; Fri, 22 Aug 2008 15:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=-0.094, 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 zyOh1MTW8zl8 for ; Fri, 22 Aug 2008 15:52:43 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id C8AC13A6965 for ; Fri, 22 Aug 2008 15:52:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=e70g91YQEuAOReR+xz0U81z9S+wWEnhSYy0SB8Ky0izQTmWqHLh+ikgF+AxMrjL6; 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 [68.164.84.32] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KWfUm-0007v9-59 for netconf@ietf.org; Fri, 22 Aug 2008 18:52:40 -0400 Message-ID: <000601c904a9$f82c3280$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "netconf mailing list" References: <200808221925.m7MJPjDp031133@idle.juniper.net> Date: Fri, 22 Aug 2008 15:53:59 -0700 MIME-Version: 1.0 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3bf480a83413d71df8c28f2689be64373350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.84.32 Subject: Re: [Netconf] New work: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi - > From: "Simon Leinen" > To: "Phil Shafer" > Cc: "Randy Presuhn" ; "netconf mailing list" > Sent: Friday, August 22, 2008 3:39 PM > Subject: Re: [Netconf] New work: with-defaults > > Phil Shafer writes: > > "Randy Presuhn" writes: > >> This seems surprising if the point of having defaults was to avoid > >> the need to shovel those values back and forth. If default values > >> are part of the interface contract between client and server, then > >> how something came to have a value equal to the default shouldn't > >> be a factor. > > > Many of my customers like to say "set mtu 1500" even though they > > know it's the default. They like to explicitly set it and see it. > > Thanks for bringing up the MTU example. This reminds me of why I > strongly agree with Phil here: It is important to distinguish between > an unset parameter and a parameter that has bFrom netconf-bounces@ietf.org Fri Aug 22 15:52:45 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57C493A6A29; Fri, 22 Aug 2008 15:52:45 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11D773A6A29 for ; Fri, 22 Aug 2008 15:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=-0.094, 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 zyOh1MTW8zl8 for ; Fri, 22 Aug 2008 15:52:43 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id C8AC13A6965 for ; Fri, 22 Aug 2008 15:52:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=e70g91YQEuAOReR+xz0U81z9S+wWEnhSYy0SB8Ky0izQTmWqHLh+ikgF+AxMrjL6; 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 [68.164.84.32] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KWfUm-0007v9-59 for netconf@ietf.org; Fri, 22 Aug 2008 18:52:40 -0400 Message-ID: <000601c904a9$f82c3280$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "netconf mailing list" References: <200808221925.m7MJPjDp031133@idle.juniper.net> Date: Fri, 22 Aug 2008 15:53:59 -0700 MIME-Version: 1.0 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3bf480a83413d71df8c28f2689be64373350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.84.32 Subject: Re: [Netconf] New work: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi - > From: "Simon Leinen" > To: "Phil Shafer" > Cc: "Randy Presuhn" ; "netconf mailing list" > Sent: Friday, August 22, 2008 3:39 PM > Subject: Re: [Netconf] New work: with-defaults > > Phil Shafer writes: > > "Randy Presuhn" writes: > >> This seems surprising if the point of having defaults was to avoid > >> the need to shovel those values back and forth. If default values > >> are part of the interface contract between client and server, then > >> how something came to have a value equal to the default shouldn't > >> be a factor. > > > Many of my customers like to say "set mtu 1500" even though they > > know it's the default. They like to explicitly set it and see it. > > Thanks for bringing up the MTU example. This reminds me of why I > strongly agree with Phil here: It is important to distinguish between > an unset parameter and a parameter that has been explicitly configured > to a value that happens to match the default. > > Here's a true story from an operator: > > There's a brand of router we and many other people use. When > configuring a tunnel interface, the configuration default for the MTU > is derived from the MTU of the interface towards the remote endpoint. > > Operationally, it is usually required to have equal MTU sizes on both > ends of the tunnel (different routers, possibly under different > administration), so we have to agree on one value. > > Now let's say that, on my router, and at the time the configuration is > entered, the agreed-upon value happens to be the same as the default > MTU - depending on which interface the route to the other endpoint > points to at that time. Because the router works according to what > Randy finds natural, as opposed to what Phil and I prefer, it will > simply ignore my configuration because it matches the default. > > This will work just fine... until my router is rebooted for some > reason. The configuration (with the MTU set to "default") is > re-interpreted in a different context, where the route to the other > endpoint may point to a different interface with a different MTU. The > result will be that the tunnel MTU is now set to some other value, > which leads to the tunnel blackholing large packets in one direction. > I have seen this happen to me, and I have heard others had the same > issue. Believe me that debugging these kinds of problems is NOT FUN. > > You may say that this wouldn't be a problem if the default MTU in this > case wasn't derived from operational state, and I sort-of agree. But > the people who wrote the software probably have good (probably > usability) arguments for doing it that way. > > > I personally find it odd when I explicitly set something, come back > > later and find it gone. > > Precisely. This example is very similar to some of the cases we worked through while looking at the netmod requirements. It actually makes a strong case for only using defaults as part of an interface contract, and explains why (1) "defaults" derived from operational state are a bad thing from a configuration management perspective. even though they may be nice when designing a human (not machine-to-machine) interface and (2) "disappearing" defaults are problematic from a machine-to-machine configuration management perspective, even though they might be desirable for some human interface use cases. Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf een explicitly configured > to a value that happens to match the default. > > Here's a true story from an operator: > > There's a brand of router we and many other people use. When > configuring a tunnel interface, the configuration default for the MTU > is derived from the MTU of the interface towards the remote endpoint. > > Operationally, it is usually required to have equal MTU sizes on both > ends of the tunnel (different routers, possibly under different > administration), so we have to agree on one value. > > Now let's say that, on my router, and at the time the configuration is > entered, the agreed-upon value happens to be the same as the default > MTU - depending on which interface the route to the other endpoint > points to at that time. Because the router works according to what > Randy finds natural, as opposed to what Phil and I prefer, it will > simply ignore my configuration because it matches the default. > > This will work just fine... until my router is rebooted for some > reason. The configuration (with the MTU set to "default") is > re-interpreted in a different context, where the route to the other > endpoint may point to a different interface with a different MTU. The > result will be that the tunnel MTU is now set to some other value, > which leads to the tunnel blackholing large packets in one direction. > I have seen this happen to me, and I have heard others had the same > issue. Believe me that debugging these kinds of problems is NOT FUN. > > You may say that this wouldn't be a problem if the default MTU in this > case wasn't derived from operational state, and I sort-of agree. But > the people who wrote the software probably have good (probably > usability) arguments for doing it that way. > > > I personally find it odd when I explicitly set something, come back > > later and find it gone. > > Precisely. This example is very similar to some of the cases we worked through while looking at the netmod requirements. It actually makes a strong case for only using defaults as part of an interface contract, and explains why (1) "defaults" derived from operational state are a bad thing from a configuration management perspective. even though they may be nice when designing a human (not machine-to-machine) interface and (2) "disappearing" defaults are problematic from a machine-to-machine configuration management perspective, even though they might be desirable for some human interface use cases. Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 22 16:27:01 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC6473A6AD6; Fri, 22 Aug 2008 16:27:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31A83A6AD9 for ; Fri, 22 Aug 2008 16:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.121, 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 a2bxOIl9Sia4 for ; Fri, 22 Aug 2008 16:26:58 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 0A4ED3A6A79 for ; Fri, 22 Aug 2008 16:26:58 -0700 (PDT) Received: (qmail 78208 invoked from network); 22 Aug 2008 23:27:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 22 Aug 2008 23:27:06 -0000 X-YMail-OSG: zZ7vJlYVM1lsIS21Llg.._.lDQwiAcHyFWPfkzUGc3Nzjd9MXIzZe.H_av9dHauGHNYI44VEOEl5dsmvT27VA6qABNJfVzlSIffKp3vZ0hwjgKo4kkSgu66BgCkcp9o- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AF4B48.9060800@netconfcentral.com> Date: Fri, 22 Aug 2008 16:27:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Randy Presuhn References: <200808221925.m7MJPjDp031133@idle.juniper.net> <000601c904a9$f82c3280$6801a8c0@oemcomputer> In-Reply-To: <000601c904a9$f82c3280$6801a8c0@oemcomputer> Cc: netconf mailing list Subject: Re: [Netconf] New work: 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Randy Presuhn wrote: > Hi - > >> From: "Simon Leinen" >> To: "Phil Shafer" >> Cc: "Randy Presuhn" ; "netconf mailing list" >> Sent: Friday, August 22, 2008 3:39 PM >> Subject: Re: [Netconf] New work: with-defaults >> >> Phil Shafer writes: >>> "Randy Presuhn" writes: >>>> This seems surprising if the point of having defaults was to avoid >>>> the need to shovel those values back and forth. If default values >>>> are part of the interface contract between client and server, then >>>> how something came to have a value equal to the default shouldn't >>>> be a factor. >>> Many of my customers like to say "set mtu 1500" even though they >>> know it's the default. They like to explicitly set it and see it. >> Thanks for bringing up the MTU example. This reminds me of why I >> strongly agree with Phil here: It is important to distinguish between >> an unset parameter and a parameter that has been explicitly configured >> to a value that happens to match the default. >> >> Here's a true story from an operator: >> >> There's a brand of router we and many other people use. When >> configuring a tunnel interface, the configuration default for the MTU >> is derived from the MTU of the interface towards the remote endpoint. >> >> Operationally, it is usually required to have equal MTU sizes on both >> ends of the tunnel (different routers, possibly under different >> administration), so we have to agree on one value. >> >> Now let's say that, on my router, and at the time the configuration is >> entered, the agreed-upon value happens to be the same as the default >> MTU - depending on which interface the route to the other endpoint >> points to at that time. Because the router works according to what >> Randy finds natural, as opposed to what Phil and I prefer, it will >> simply ignore my configuration because it matches the default. >> >> This will work just fine... until my router is rebooted for some >> reason. The configuration (with the MTU set to "default") is >> re-interpreted in a different context, where the route to the other >> endpoint may point to a different interface with a different MTU. The >> result will be that the tunnel MTU is now set to some other value, >> which leads to the tunnel blackholing large packets in one direction. >> I have seen this happen to me, and I have heard others had the same >> issue. Believe me that debugging these kinds of problems is NOT FUN. >> >> You may say that this wouldn't be a problem if the default MTU in this >> case wasn't derived from operational state, and I sort-of agree. But >> the people who wrote the software probably have good (probably >> usability) arguments for doing it that way. >> >>> I personally find it odd when I explicitly set something, come back >>> later and find it gone. >> Precisely. > > This example is very similar to some of the cases we worked through > while looking at the netmod requirements. It actually makes a strong case > for only using defaults as part of an interface contract, and explains why > (1) "defaults" derived from operational state are a bad thing from a configuration > management perspective. even though they may be nice when designing a > human (not machine-to-machine) interface and (2) "disappearing" defaults > are problematic from a machine-to-machine configuration management > perspective, even though they might be desirable for some human > interface use cases. > Even though, I still think it makes better sense all around to only filter agent-supplied values, because that is what the CLI world is used to having. It's easier to understand too. If the manager did not supply the value, it is part of the filter. It doesn't matter if the leaf value was derived from a YANG module, an XSD, a CLI command, or the operational state, or even random data. If you think about the real feature here, it is the manager saying "I know what config I supplied. Show me what you added." The two subsets should not overlap (filter true, then false). > Randy Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Aug 22 16:27:01 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC6473A6AD6; Fri, 22 Aug 2008 16:27:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31A83A6AD9 for ; Fri, 22 Aug 2008 16:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.121, 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 a2bxOIl9Sia4 for ; Fri, 22 Aug 2008 16:26:58 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 0A4ED3A6A79 for ; Fri, 22 Aug 2008 16:26:58 -0700 (PDT) Received: (qmail 78208 invoked from network); 22 Aug 2008 23:27:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 22 Aug 2008 23:27:06 -0000 X-YMail-OSG: zZ7vJlYVM1lsIS21Llg.._.lDQwiAcHyFWPfkzUGc3Nzjd9MXIzZe.H_av9dHauGHNYI44VEOEl5dsmvT27VA6qABNJfVzlSIffKp3vZ0hwjgKo4kkSgu66BgCkcp9o- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48AF4B48.9060800@netconfcentral.com> Date: Fri, 22 Aug 2008 16:27:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Randy Presuhn References: <200808221925.m7MJPjDp031133@idle.juniper.net> <000601c904a9$f82c3280$6801a8c0@oemcomputer> In-Reply-To: <000601c904a9$f82c3280$6801a8c0@oemcomputer> Cc: netconf mailing list Subject: Re: [Netconf] New work: 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Randy Presuhn wrote: > Hi - > >> From: "Simon Leinen" >> To: "Phil Shafer" >> Cc: "Randy Presuhn" ; "netconf mailing list" >> Sent: Friday, August 22, 2008 3:39 PM >> Subject: Re: [Netconf] New work: with-defaults >> >> Phil Shafer writes: >>> "Randy Presuhn" writes: >>>> This seems surprising if the point of having defaults was to avoid >>>> the need to shovel those values back and forth. If default values >>>> are part of the interface contract between client and server, then >>>> how something came to have a value equal to the default shouldn't >>>> be a factor. >>> Many of my customers like to say "set mtu 1500" even though they >>> know it's the default. They like to explicitly set it and see it. >> Thanks for bringing up the MTU example. This reminds me of why I >> strongly agree with Phil here: It is important to distinguish between >> an unset parameter and a parameter that has been explicitly configured >> to a value that happens to match the default. >> >> Here's a true story from an operator: >> >> There's a brand of router we and many other people use. When >> configuring a tunnel interface, the configuration default for the MTU >> is derived from the MTU of the interface towards the remote endpoint. >> >> Operationally, it is usually required to have equal MTU sizes on both >> ends of the tunnel (different routers, possibly under different >> administration), so we have to agree on one value. >> >> Now let's say that, on my router, and at the time the configuration is >> entered, the agreed-upon value happens to be the same as the default >> MTU - depending on which interface the route to the other endpoint >> points to at that time. Because the router works according to what >> Randy finds natural, as opposed to what Phil and I prefer, it will >> simply ignore my configuration because it matches the default. >> >> This will work just fine... until my router is rebooted for some >> reason. The configuration (with the MTU set to "default") is >> re-interpreted in a different context, where the route to the other >> endpoint may point to a different interface with a different MTU. The >> result will be that the tunnel MTU is now set to some other value, >> which leads to the tunnel blackholing large packets in one direction. >> I have seen this happen to me, and I have heard others had the same >> issue. Believe me that debugging these kinds of problems is NOT FUN. >> >> You may say that this wouldn't be a problem if the default MTU in this >> case wasn't derived from operational state, and I sort-of agree. But >> the people who wrote the software probably have good (probably >> usability) arguments for doing it that way. >> >>> I personally find it odd when I explicitly set something, come back >>> later and find it gone. >> Precisely. > > This example is very similar to some of the cases we worked through > while looking at the netmod requirements. It actually makes a strong case > for only using defaults as part of an interface contract, and explains why > (1) "defaults" derived from operational state are a bad thing from a configuration > management perspective. even though they may be nice when designing a > human (not machine-to-machine) interface and (2) "disappearing" defaults > are problematic from a machine-to-machine configuration management > perspective, even though they might be desirable for some human > interface use cases. > Even though, I still think it makes better sense all around to only filter agent-supplied values, because that is what the CLI world is used to having. It's easier to understand too. If the manager did not supply the value, it is part of the filter. It doesn't matter if the leaf value was derived from a YANG module, an XSD, a CLI command, or the operational state, or even random data. If you think about the real feature here, it is the manager saying "I know what config I supplied. Show me what you added." The two subsets should not overlap (filter true, then false). > Randy Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Aug 23 02:42:01 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F08723A6920; Sat, 23 Aug 2008 02:42:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 823833A6920 for ; Sat, 23 Aug 2008 02:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.129, 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 3Nekm58n7WRi for ; Sat, 23 Aug 2008 02:41:58 -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 A375C3A6909 for ; Sat, 23 Aug 2008 02:41:58 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 5817476C4C8; Sat, 23 Aug 2008 11:40:48 +0200 (CEST) Date: Sat, 23 Aug 2008 11:40:45 +0200 (CEST) Message-Id: <20080823.114045.257185740.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200808221253.m7MCrEnx027668@idle.juniper.net> References: <48ADD556.1040209@netconfcentral.com> <200808221253.m7MCrEnx027668@idle.juniper.net> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] New work: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: > >Another detail: this capability does not differentiate > >between a value set by the manager or the agent. If > >the default is '3' and the value is '3', it is considered > >to contain the default, regardless of how it was created. > > This is another can o' worms. Yes. > I preserve user specified values > even when the value matches the default. So do I, and I think doing otherwise violates the Principle of Least Anstonishment. If I set a value I expect it to be there. We don't have upgrade rules yet, so we don't know if it will be ok to change default values in new revisions. But in reality default values are changed over time. If a client explicitly sets 'foo' to a value which happens to be the default, and 'foo' gets a new default in a new revision, the explicitly set value has been silently changed by the box. (A valid use case is for the client to explicitly reset a knob to its default value, but that is covered already). So I wonder why this capability has to talk about this at all? Just as the rest of the default semantics are left to the data model, I think this should be as well. This is a NETCONF (data-model agnostic) capability. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Aug 23 02:42:01 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F08723A6920; Sat, 23 Aug 2008 02:42:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 823833A6920 for ; Sat, 23 Aug 2008 02:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.129, 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 3Nekm58n7WRi for ; Sat, 23 Aug 2008 02:41:58 -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 A375C3A6909 for ; Sat, 23 Aug 2008 02:41:58 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 5817476C4C8; Sat, 23 Aug 2008 11:40:48 +0200 (CEST) Date: Sat, 23 Aug 2008 11:40:45 +0200 (CEST) Message-Id: <20080823.114045.257185740.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200808221253.m7MCrEnx027668@idle.juniper.net> References: <48ADD556.1040209@netconfcentral.com> <200808221253.m7MCrEnx027668@idle.juniper.net> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] New work: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: > >Another detail: this capability does not differentiate > >between a value set by the manager or the agent. If > >the default is '3' and the value is '3', it is considered > >to contain the default, regardless of how it was created. > > This is another can o' worms. Yes. > I preserve user specified values > even when the value matches the default. So do I, and I think doing otherwise violates the Principle of Least Anstonishment. If I set a value I expect it to be there. We don't have upgrade rules yet, so we don't know if it will be ok to change default values in new revisions. But in reality default values are changed over time. If a client explicitly sets 'foo' to a value which happens to be the default, and 'foo' gets a new default in a new revision, the explicitly set value has been silently changed by the box. (A valid use case is for the client to explicitly reset a knob to its default value, but that is covered already). So I wonder why this capability has to talk about this at all? Just as the rest of the default semantics are left to the data model, I think this should be as well. This is a NETCONF (data-model agnostic) capability. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Aug 23 03:03:29 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21EBE3A6B77; Sat, 23 Aug 2008 03:03:29 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722D03A6B72 for ; Sat, 23 Aug 2008 03:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oGfcQxAKqPy for ; Sat, 23 Aug 2008 03:03:26 -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 A6BB23A6B77 for ; Sat, 23 Aug 2008 03:03:26 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id C409076C4C8; Sat, 23 Aug 2008 12:02:55 +0200 (CEST) Date: Sat, 23 Aug 2008 12:02:52 +0200 (CEST) Message-Id: <20080823.120252.121042327.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <000601c904a9$f82c3280$6801a8c0@oemcomputer> References: <200808221925.m7MJPjDp031133@idle.juniper.net> <000601c904a9$f82c3280$6801a8c0@oemcomputer> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] New work: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Randy Presuhn" wrote: > This example is very similar to some of the cases we worked through > while looking at the netmod requirements. It actually makes a strong case > for only using defaults as part of an interface contract, and explains why > (1) "defaults" derived from operational state are a bad thing from a > configuration management perspective. I agree. IMO these objects should be explicitly created by the server, and thus not marked as defaults, and reported regardless of the value of with-defaults. (In YANG terms, such an object would me marked with "created-by system;") /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Aug 23 03:03:29 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21EBE3A6B77; Sat, 23 Aug 2008 03:03:29 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722D03A6B72 for ; Sat, 23 Aug 2008 03:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oGfcQxAKqPy for ; Sat, 23 Aug 2008 03:03:26 -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 A6BB23A6B77 for ; Sat, 23 Aug 2008 03:03:26 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTPSA id C409076C4C8; Sat, 23 Aug 2008 12:02:55 +0200 (CEST) Date: Sat, 23 Aug 2008 12:02:52 +0200 (CEST) Message-Id: <20080823.120252.121042327.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <000601c904a9$f82c3280$6801a8c0@oemcomputer> References: <200808221925.m7MJPjDp031133@idle.juniper.net> <000601c904a9$f82c3280$6801a8c0@oemcomputer> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] New work: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Randy Presuhn" wrote: > This example is very similar to some of the cases we worked through > while looking at the netmod requirements. It actually makes a strong case > for only using defaults as part of an interface contract, and explains why > (1) "defaults" derived from operational state are a bad thing from a > configuration management perspective. I agree. IMO these objects should be explicitly created by the server, and thus not marked as defaults, and reported regardless of the value of with-defaults. (In YANG terms, such an object would me marked with "created-by system;") /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Aug 23 12:41:38 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910F73A6C1A; Sat, 23 Aug 2008 12:41:38 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47BC53A6C1A for ; Sat, 23 Aug 2008 12:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=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 5DEKVhMpePx2 for ; Sat, 23 Aug 2008 12:41:36 -0700 (PDT) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by core3.amsl.com (Postfix) with SMTP id 4D6173A68C8 for ; Sat, 23 Aug 2008 12:41:33 -0700 (PDT) Received: (qmail 62873 invoked from network); 23 Aug 2008 19:41:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 23 Aug 2008 19:41:30 -0000 X-YMail-OSG: 3G65DJsVM1kWUJnoo2glNk5veFJY.J6kys9iglagSc0UHUNGqubFFczh_Al67cz8sQcZxd0qIK0etkfm52sErx9AnlWeqRUQO_KacPCFkA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B067E8.7040206@netconfcentral.com> Date: Sat, 23 Aug 2008 12:41:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group , NETCONF Subject: [Netconf] error-app-tag QName? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Martin brought this up a long time ago, but maybe now is time to fix error-app-tag before it gets too hard to change it later. Right now, an application cannot use the string in a multi-module-publisher environment (gee, all of them) because there is no way to tell error-app-tag values apart from different vendors. There are also no definitions within YANG, so no way to associate them with a given module. Instead of the xsd:string data type we have now: my-error We should be using a xsd:QName instead: acme:my-error In this way, vendors and IETF WGs can define their own error-app-tags without any need for a centralized registry. An empty XML element works the same in YANG as a plain OBJECT-IDENTIFIER in SMIv2. But what prefix/namespace to use for the YANG error codes? YANG needs an XSD anyway to define the insert and key XML attributes, so that XSD can contain some empty elements for registration points YANG error-app-tag identifier for an unique statement violation during the validation of a NETCONF configuration database. ... yang:data-not-unique Note that YANG cannot support the definition of a registration QName (element name) because it would be interFrom netconf-bounces@ietf.org Sat Aug 23 12:41:38 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910F73A6C1A; Sat, 23 Aug 2008 12:41:38 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47BC53A6C1A for ; Sat, 23 Aug 2008 12:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=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 5DEKVhMpePx2 for ; Sat, 23 Aug 2008 12:41:36 -0700 (PDT) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by core3.amsl.com (Postfix) with SMTP id 4D6173A68C8 for ; Sat, 23 Aug 2008 12:41:33 -0700 (PDT) Received: (qmail 62873 invoked from network); 23 Aug 2008 19:41:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.85.233 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 23 Aug 2008 19:41:30 -0000 X-YMail-OSG: 3G65DJsVM1kWUJnoo2glNk5veFJY.J6kys9iglagSc0UHUNGqubFFczh_Al67cz8sQcZxd0qIK0etkfm52sErx9AnlWeqRUQO_KacPCFkA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B067E8.7040206@netconfcentral.com> Date: Sat, 23 Aug 2008 12:41:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETMOD Working Group , NETCONF Subject: [Netconf] error-app-tag QName? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Martin brought this up a long time ago, but maybe now is time to fix error-app-tag before it gets too hard to change it later. Right now, an application cannot use the string in a multi-module-publisher environment (gee, all of them) because there is no way to tell error-app-tag values apart from different vendors. There are also no definitions within YANG, so no way to associate them with a given module. Instead of the xsd:string data type we have now: my-error We should be using a xsd:QName instead: acme:my-error In this way, vendors and IETF WGs can define their own error-app-tags without any need for a centralized registry. An empty XML element works the same in YANG as a plain OBJECT-IDENTIFIER in SMIv2. But what prefix/namespace to use for the YANG error codes? YANG needs an XSD anyway to define the insert and key XML attributes, so that XSD can contain some empty elements for registration points YANG error-app-tag identifier for an unique statement violation during the validation of a NETCONF configuration database. ... yang:data-not-unique Note that YANG cannot support the definition of a registration QName (element name) because it would bepreted as a database leaf, not a registration leaf. What if we had a generic object identifier statement for YANG, that was top-level only (body-stmt), and was used to define the YANG equivalent of registration OIDs? module yang { ... identifier data-not-unique { status current; description "YANG error-app-tag identifier for an unique statement violation during the validation of a NETCONF configuration database."; reference "draft-ietf-netmod-yang-00.txt, sec. E.1"; } ... } Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf interpreted as a database leaf, not a registration leaf. What if we had a generic object identifier statement for YANG, that was top-level only (body-stmt), and was used to define the YANG equivalent of registration OIDs? module yang { ... identifier data-not-unique { status current; description "YANG error-app-tag identifier for an unique statement violation during the validation of a NETCONF configuration database."; reference "draft-ietf-netmod-yang-00.txt, sec. E.1"; } ... } Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Aug 24 19:48:58 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72F33A690C; Sun, 24 Aug 2008 19:48:58 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF973A690C for ; Sun, 24 Aug 2008 19:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4g4eTlYWD2yZ for ; Sun, 24 Aug 2008 19:48:56 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 9BA353A68AF for ; Sun, 24 Aug 2008 19:48:54 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Sun, 24 Aug 2008 19:48:10 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Aug 2008 19:48:15 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Aug 2008 19:48:14 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Aug 2008 19:48:13 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7P2mDu75770; Sun, 24 Aug 2008 19:48:13 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7P2ife4051719; Mon, 25 Aug 2008 02:44:41 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808250244.m7P2ife4051719@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080823.114045.257185740.mbj@tail-f.com> Date: Sun, 24 Aug 2008 22:44:41 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Aug 2008 02:48:13.0972 (UTC) FILETIME=[04D76540:01C9065D] Cc: netconf@ietf.org Subject: Re: [Netconf] New work: 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund writes: >So do I, and I think doing otherwise violates the Principle of Least >Anstonishment. If I set a value I expect it to be there. Amen. >So I wonder why this capability has to talk about this at all? Just >as the rest of the default semantics are left to the data model, I >think this should be as well. This is a NETCONF (data-model agnostic) >capability. I think this is a matter for us to dictate for all YANG-based models. It's not something that can (or should) be dictated for all NETCONF-based data models, since NETCONF has no rules about what one can do here. I'd rather explicitly specify a fixed behavior in YANG than retrofit it in NETCONF. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Aug 24 19:48:58 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72F33A690C; Sun, 24 Aug 2008 19:48:58 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF973A690C for ; Sun, 24 Aug 2008 19:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4g4eTlYWD2yZ for ; Sun, 24 Aug 2008 19:48:56 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 9BA353A68AF for ; Sun, 24 Aug 2008 19:48:54 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Sun, 24 Aug 2008 19:48:10 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Aug 2008 19:48:15 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Aug 2008 19:48:14 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Aug 2008 19:48:13 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7P2mDu75770; Sun, 24 Aug 2008 19:48:13 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7P2ife4051719; Mon, 25 Aug 2008 02:44:41 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808250244.m7P2ife4051719@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080823.114045.257185740.mbj@tail-f.com> Date: Sun, 24 Aug 2008 22:44:41 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Aug 2008 02:48:13.0972 (UTC) FILETIME=[04D76540:01C9065D] Cc: netconf@ietf.org Subject: Re: [Netconf] New work: 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund writes: >So do I, and I think doing otherwise violates the Principle of Least >Anstonishment. If I set a value I expect it to be there. Amen. >So I wonder why this capability has to talk about this at all? Just >as the rest of the default semantics are left to the data model, I >think this should be as well. This is a NETCONF (data-model agnostic) >capability. I think this is a matter for us to dictate for all YANG-based models. It's not something that can (or should) be dictated for all NETCONF-based data models, since NETCONF has no rules about what one can do here. I'd rather explicitly specify a fixed behavior in YANG than retrofit it in NETCONF. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Aug 24 19:51:03 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35E423A6972; Sun, 24 Aug 2008 19:51:03 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 308783A68AF for ; Sun, 24 Aug 2008 19:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sagPBSqSTyMs for ; Sun, 24 Aug 2008 19:51:01 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id F34333A6972 for ; Sun, 24 Aug 2008 19:51:00 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Sun, 24 Aug 2008 19:49:07 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Aug 2008 19:50:52 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Aug 2008 19:50:51 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Aug 2008 19:50:51 -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 m7P2oou76598; Sun, 24 Aug 2008 19:50:51 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7P2lIeL051754; Mon, 25 Aug 2008 02:47:19 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808250247.m7P2lIeL051754@idle.juniper.net> To: "Randy Presuhn" In-reply-to: <000601c904a9$f82c3280$6801a8c0@oemcomputer> Date: Sun, 24 Aug 2008 22:47:18 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Aug 2008 02:50:51.0251 (UTC) FILETIME=[62964430:01C9065D] Cc: netconf mailing list Subject: Re: [Netconf] New work: 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Randy Presuhn" writes: >This example is very similar to some of the cases we worked through >while looking at the netmod requirements. It actually makes a strong case >for only using defaults as part of an interface contract, and explains why >(1) "defaults" derived from operational state are a bad thing from a configura >tion >management perspective. even though they may be nice when designing a >human (not machine-to-machine) interface and State-derived defaults may not be nice, but they are definitely real world. > (2) "disappearing" defaults >are problematic from a machine-to-machine configuration management >perspective, even though they might be desirable for some human >interface use cases. IMHO disappearing defaults are problematic for humans also. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Aug 24 19:51:03 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35E423A6972; Sun, 24 Aug 2008 19:51:03 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 308783A68AF for ; Sun, 24 Aug 2008 19:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sagPBSqSTyMs for ; Sun, 24 Aug 2008 19:51:01 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id F34333A6972 for ; Sun, 24 Aug 2008 19:51:00 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Sun, 24 Aug 2008 19:49:07 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Aug 2008 19:50:52 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Aug 2008 19:50:51 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Aug 2008 19:50:51 -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 m7P2oou76598; Sun, 24 Aug 2008 19:50:51 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7P2lIeL051754; Mon, 25 Aug 2008 02:47:19 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808250247.m7P2lIeL051754@idle.juniper.net> To: "Randy Presuhn" In-reply-to: <000601c904a9$f82c3280$6801a8c0@oemcomputer> Date: Sun, 24 Aug 2008 22:47:18 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Aug 2008 02:50:51.0251 (UTC) FILETIME=[62964430:01C9065D] Cc: netconf mailing list Subject: Re: [Netconf] New work: 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Randy Presuhn" writes: >This example is very similar to some of the cases we worked through >while looking at the netmod requirements. It actually makes a strong case >for only using defaults as part of an interface contract, and explains why >(1) "defaults" derived from operational state are a bad thing from a configura >tion >management perspective. even though they may be nice when designing a >human (not machine-to-machine) interface and State-derived defaults may not be nice, but they are definitely real world. > (2) "disappearing" defaults >are problematic from a machine-to-machine configuration management >perspective, even though they might be desirable for some human >interface use cases. IMHO disappearing defaults are problematic for humans also. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Aug 25 02:26:17 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DBE73A69E7; Mon, 25 Aug 2008 02:26:17 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CE113A69E7 for ; Mon, 25 Aug 2008 02:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 X55yqrr2xaZB for ; Mon, 25 Aug 2008 02:26:14 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 50B793A69D8 for ; Mon, 25 Aug 2008 02:26:14 -0700 (PDT) Received: (qmail 51105 invoked from network); 25 Aug 2008 09:05:26 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 25 Aug 2008 09:05:26 -0000 Message-ID: <2E7964AA249F4CEBB499F03FEE7EDE1B@BertLaptop> From: "Bert Wijnen \(IETF\)" To: References: In-Reply-To: Date: Mon, 25 Aug 2008 11:04:37 +0200 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: [Netconf] extended WGLC (till Sept 1st) for draft-ietf-netconf-partial-lock-03.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear WG members, we have had very little feedback on this WG Last Call. It is quite possible that many of you were/are on vacation. So we are extending the WGLC till Sept 1st. PLEASE .... DO review and send your comments Also, if you are OK with the document to move forward (that is to request publication as a standards track RFC), then it would be great if you could say so on the mailing list. If we do not get any feedback, how can we as WG chairs determine that we have WG concensus to move forward? We cannot take silence as consent. PLEASE. Bert and Mehmet. ----- Original Message ----- From: "Ersue, Mehmet (NSN - DE/Munich)" To: Cc: "ext Bert Wijnen (IETF)" Sent: Sunday, August 10, 2008 1:30 PM Subject: WGLC for draft-ietf-netconf-partial-lock-03.txt Hi All, as discussed in the NETCONF session Balazs updated the draft "Partial Lock RPC for NETCONF" (see http://tools.ietf.org/html/draft-ietf-netconf-partial-lock-03). The draft has been discussed in this group and appears to be stable for WGLC. With this mail we start a WGLC for the Partial Lock draft, which is proposed to publish as a Proposed Standard RFC. The WGLC starts on August 10, 2008 and will run for two weeks until August 24, 2008. Everybody on the NETCONF WG please review the draft again and send your comments to the NETCONF maillist. Thank you and looking forward From netconf-bounces@ietf.org Mon Aug 25 02:26:17 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DBE73A69E7; Mon, 25 Aug 2008 02:26:17 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CE113A69E7 for ; Mon, 25 Aug 2008 02:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 X55yqrr2xaZB for ; Mon, 25 Aug 2008 02:26:14 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 50B793A69D8 for ; Mon, 25 Aug 2008 02:26:14 -0700 (PDT) Received: (qmail 51105 invoked from network); 25 Aug 2008 09:05:26 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 25 Aug 2008 09:05:26 -0000 Message-ID: <2E7964AA249F4CEBB499F03FEE7EDE1B@BertLaptop> From: "Bert Wijnen \(IETF\)" To: References: In-Reply-To: Date: Mon, 25 Aug 2008 11:04:37 +0200 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: [Netconf] extended WGLC (till Sept 1st) for draft-ietf-netconf-partial-lock-03.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear WG members, we have had very little feedback on this WG Last Call. It is quite possible that many of you were/are on vacation. So we are extending the WGLC till Sept 1st. PLEASE .... DO review and send your comments Also, if you are OK with the document to move forward (that is to request publication as a standards track RFC), then it would be great if you could say so on the mailing list. If we do not get any feedback, how can we as WG chairs determine that we have WG concensus to move forward? We cannot take silence as consent. PLEASE. Bert and Mehmet. ----- Original Message ----- From: "Ersue, Mehmet (NSN - DE/Munich)" To: Cc: "ext Bert Wijnen (IETF)" Sent: Sunday, August 10, 2008 1:30 PM Subject: WGLC for draft-ietf-netconf-partial-lock-03.txt Hi All, as discussed in the NETCONF session Balazs updated the draft "Partial Lock RPC for NETCONF" (see http://tools.ietf.org/html/draft-ietf-netconf-partial-lock-03). The draft has been discussed in this group and appears to be stable for WGLC. With this mail we start a WGLC for the Partial Lock draft, which is proposed to publish as a Proposed Standard RFC. The WGLC starts on August 10, 2008 and will run for two weeks until August 24, 2008. Everybody on the NETCONF WG please review the draft again and send your comments to the NETCONF maillist. Thank you and looking fofor your reviews and comments. Cheers, Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf rward for your reviews and comments. Cheers, Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Aug 25 09:14:21 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 725CC3A682F; Mon, 25 Aug 2008 09:14:21 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5E13A6810 for ; Mon, 25 Aug 2008 09:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dph7xLTavbzU for ; Mon, 25 Aug 2008 09:14:19 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id BD49B3A67A4 for ; Mon, 25 Aug 2008 09:14:18 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B49ED206BA; Mon, 25 Aug 2008 18:13:19 +0200 (CEST) X-AuditID: c1b4fb3c-ae0cebb0000015b5-a4-48b2da1f9158 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9EF4D203CA; Mon, 25 Aug 2008 18:13:19 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Aug 2008 18:13:19 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Aug 2008 18:13:19 +0200 Message-ID: <48B2D9F0.5010507@ericsson.com> Date: Mon, 25 Aug 2008 18:12:32 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <200808221925.m7MJPjDp031133@idle.juniper.net> <000601c904a9$f82c3280$6801a8c0@oemcomputer> <20080823.120252.121042327.mbj@tail-f.com> In-Reply-To: <20080823.120252.121042327.mbj@tail-f.com> X-OriginalArrivalTime: 25 Aug 2008 16:13:19.0191 (UTC) FILETIME=[7CFEDE70:01C906CD] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] New work: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, While I agree with the principle, some devices might not store the difference between a leaf set to 5 explicitly and a leaf that only has a 5 as a default value. (We have such devices :-( So mandating this might be a tall order for some nodes. Balazs Martin Bjorklund wrote: > "Randy Presuhn" wrote: >> This example is very similar to some of the cases we worked through >> while looking at the netmod requirements. It actually makes a strong case >> for only using defaults as part of an interface contract, and explains why >> (1) "defaults" derived from operational state are a bad thing from a >> configuration management perspective. > > I agree. IMO these objects should be explicitly created by the > server, and thus not marked as defaults, and reported regardleFrom netconf-bounces@ietf.org Mon Aug 25 09:14:21 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 725CC3A682F; Mon, 25 Aug 2008 09:14:21 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5E13A6810 for ; Mon, 25 Aug 2008 09:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dph7xLTavbzU for ; Mon, 25 Aug 2008 09:14:19 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id BD49B3A67A4 for ; Mon, 25 Aug 2008 09:14:18 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B49ED206BA; Mon, 25 Aug 2008 18:13:19 +0200 (CEST) X-AuditID: c1b4fb3c-ae0cebb0000015b5-a4-48b2da1f9158 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9EF4D203CA; Mon, 25 Aug 2008 18:13:19 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Aug 2008 18:13:19 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Aug 2008 18:13:19 +0200 Message-ID: <48B2D9F0.5010507@ericsson.com> Date: Mon, 25 Aug 2008 18:12:32 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <200808221925.m7MJPjDp031133@idle.juniper.net> <000601c904a9$f82c3280$6801a8c0@oemcomputer> <20080823.120252.121042327.mbj@tail-f.com> In-Reply-To: <20080823.120252.121042327.mbj@tail-f.com> X-OriginalArrivalTime: 25 Aug 2008 16:13:19.0191 (UTC) FILETIME=[7CFEDE70:01C906CD] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] New work: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, While I agree with the principle, some devices might not store the difference between a leaf set to 5 explicitly and a leaf that only has a 5 as a default value. (We have such devices :-( So mandating this might be a tall order for some nodes. Balazs Martin Bjorklund wrote: > "Randy Presuhn" wrote: >> This example is very similar to some of the cases we worked through >> while looking at the netmod requirements. It actually makes a strong case >> for only using defaults as part of an interface contract, and explains why >> (1) "defaults" derived from operational state are a bad thing from a >> configuration management perspective. > > I agree. IMO these objects should be explicitly created by the > server, and thus not marked as defaults, and reported regardless of ss of > the value of with-defaults. (In YANG terms, such an object would me > marked with "created-by system;") > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf > the value of with-defaults. (In YANG terms, such an object would me > marked with "created-by system;") > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Aug 25 09:42:30 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0992E3A6823; Mon, 25 Aug 2008 09:42:30 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B74D3A6814 for ; Mon, 25 Aug 2008 09:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maH3-TlwGaWM for ; Mon, 25 Aug 2008 09:42:17 -0700 (PDT) Received: from chip3og57.obsmtp.com (chip3og57.obsmtp.com [64.18.14.179]) by core3.amsl.com (Postfix) with ESMTP id 2E6463A67E9 for ; Mon, 25 Aug 2008 09:42:06 -0700 (PDT) Received: from source ([66.129.228.6]) by chip3ob57.postini.com ([64.18.6.12]) with SMTP; Mon, 25 Aug 2008 09:41:47 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 09:40:34 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 09:40:34 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 09:40: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 m7PGeXu08413; Mon, 25 Aug 2008 09:40:33 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7PGb0pk058148; Mon, 25 Aug 2008 16:37:00 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808251637.m7PGb0pk058148@idle.juniper.net> To: Balazs Lengyel In-reply-to: <48B2D9F0.5010507@ericsson.com> Date: Mon, 25 Aug 2008 12:37:00 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Aug 2008 16:40:33.0691 (UTC) FILETIME=[4B3BC6B0:01C906D1] Cc: netconf@ietf.org Subject: Re: [Netconf] New work: 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel writes: >While I agree with the principle, some devices might not store the difference >between a leaf >set to 5 explicitly and a leaf that only has a 5 as a default value. (We have >such devices :-( Many devices have mimiced IOS behavior in this regard, which is part of the yang draft says: A NETCONF server that replies to a or request MAY choose not to send the leaf element if its value is the default value. I prefer (vastly) the "keep values explicitly set" behavior, so we allow device to choose their own path. The client needs to be able to handle devices that work both ways: Thus, a client that receives an for a or request, must be prepared to handle the case that a leaf node with a default value is not present in the XML. In this case, the value used by the server is known to be the default value. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Aug 25 09:42:30 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0992E3A6823; Mon, 25 Aug 2008 09:42:30 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B74D3A6814 for ; Mon, 25 Aug 2008 09:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maH3-TlwGaWM for ; Mon, 25 Aug 2008 09:42:17 -0700 (PDT) Received: from chip3og57.obsmtp.com (chip3og57.obsmtp.com [64.18.14.179]) by core3.amsl.com (Postfix) with ESMTP id 2E6463A67E9 for ; Mon, 25 Aug 2008 09:42:06 -0700 (PDT) Received: from source ([66.129.228.6]) by chip3ob57.postini.com ([64.18.6.12]) with SMTP; Mon, 25 Aug 2008 09:41:47 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 09:40:34 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 09:40:34 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 09:40: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 m7PGeXu08413; Mon, 25 Aug 2008 09:40:33 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7PGb0pk058148; Mon, 25 Aug 2008 16:37:00 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808251637.m7PGb0pk058148@idle.juniper.net> To: Balazs Lengyel In-reply-to: <48B2D9F0.5010507@ericsson.com> Date: Mon, 25 Aug 2008 12:37:00 -0400 From: Phil Shafer X-OriginalArrivalTime: 25 Aug 2008 16:40:33.0691 (UTC) FILETIME=[4B3BC6B0:01C906D1] Cc: netconf@ietf.org Subject: Re: [Netconf] New work: 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel writes: >While I agree with the principle, some devices might not store the difference >between a leaf >set to 5 explicitly and a leaf that only has a 5 as a default value. (We have >such devices :-( Many devices have mimiced IOS behavior in this regard, which is part of the yang draft says: A NETCONF server that replies to a or request MAY choose not to send the leaf element if its value is the default value. I prefer (vastly) the "keep values explicitly set" behavior, so we allow device to choose their own path. The client needs to be able to handle devices that work both ways: Thus, a client that receives an for a or request, must be prepared to handle the case that a leaf node with a default value is not present in the XML. In this case, the value used by the server is known to be the default value. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Aug 26 12:40:17 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 437443A6951; Tue, 26 Aug 2008 12:40:17 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C0C63A6AAD for ; Tue, 26 Aug 2008 12:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-b-ZYDVUWFY for ; Tue, 26 Aug 2008 12:40:15 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 49F7C3A6849 for ; Tue, 26 Aug 2008 12:40:15 -0700 (PDT) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA03.westchester.pa.mail.comcast.net with comcast id 736y1a00U0SCNGk537fa54; Tue, 26 Aug 2008 19:39:34 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA09.westchester.pa.mail.comcast.net with comcast id 77fZ1a00D4HwxpC3V7fZuN; Tue, 26 Aug 2008 19:39:34 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=04hA2PZAldicdtZkhUoA:9 a=tcTjBMT8cxK9VjPOkeoA:7 a=YLjGrqh0xSg0RN4NYPputW39PrIA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Phil Shafer'" , "'Balazs Lengyel'" References: <48B2D9F0.5010507@ericsson.com> <200808251637.m7PGb0pk058148@idle.juniper.net> Date: Tue, 26 Aug 2008 15:39:33 -0400 Message-ID: <025c01c907b3$7765f200$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200808251637.m7PGb0pk058148@idle.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AckG0ZHA0sqxZGdyT06XT1ApcAlIRAA37Vtg Cc: netconf@ietf.org Subject: Re: [Netconf] New work: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Be conservative in what you send and liberal in what you receive. I do not think we should leave it up to each server to decide for itself what to return; we need to specify what is the correct behavior for compliance to the standard, so we have something that is interoperable. Will legacy devices already support this feature of a brand new standard? of course not. We should design the standard for interoperability, not to make all existing devices able to claim compliance based on their current CLI behavior. If an existing device has a CLI that already keeps track of whether values are explicitly set or defaults, then those devices have a leg up on meeting the netconf standard; those that do not do this in their CLI will need to add the capability in the netconf implementation. The client should be able to handle responses of any approach, because the client should be able to handle non-compliant responses without crashing. Are we trying to standardize things to work more interoperably in the future, or to mimic all of the non-interoperable choices made by vendors in the past? dbh > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Phil Shafer > Sent: Monday, August 25, 2008 12:37 PM > To: Balazs Lengyel > Cc: netconf@ietf.org > Subject: Re: [Netconf] New work: with-defaults > > Balazs Lengyel writes: > >While I agree with the principle, some devices might not > store the difference > >between a leaf > >set to 5 explicitly and a leaf that only has a 5 as a > default value. (We have > >such devices :-( > > Many devices have mimiced IOS behavior in this regard, which is > part of the yang draft says: > > A NETCONF server that replies to a or request > MAY choose not to send the leaf element if its value is the > default value. > > I prefer (vastly) the "keep values explicitly set" behavior, so we > allow device to choose their own path. The client needs to be able > to handle devices that work both ways: > > Thus, a client that receives an for a or > request, must be prepared to handle the case that > a leaf node with a default value is not present in the XML. In > this case, the value used by the server is known to be the > default value. > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Aug 26 12:40:17 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 437443A6951; Tue, 26 Aug 2008 12:40:17 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C0C63A6AAD for ; Tue, 26 Aug 2008 12:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-b-ZYDVUWFY for ; Tue, 26 Aug 2008 12:40:15 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 49F7C3A6849 for ; Tue, 26 Aug 2008 12:40:15 -0700 (PDT) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA03.westchester.pa.mail.comcast.net with comcast id 736y1a00U0SCNGk537fa54; Tue, 26 Aug 2008 19:39:34 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA09.westchester.pa.mail.comcast.net with comcast id 77fZ1a00D4HwxpC3V7fZuN; Tue, 26 Aug 2008 19:39:34 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=04hA2PZAldicdtZkhUoA:9 a=tcTjBMT8cxK9VjPOkeoA:7 a=YLjGrqh0xSg0RN4NYPputW39PrIA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Phil Shafer'" , "'Balazs Lengyel'" References: <48B2D9F0.5010507@ericsson.com> <200808251637.m7PGb0pk058148@idle.juniper.net> Date: Tue, 26 Aug 2008 15:39:33 -0400 Message-ID: <025c01c907b3$7765f200$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200808251637.m7PGb0pk058148@idle.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AckG0ZHA0sqxZGdyT06XT1ApcAlIRAA37Vtg Cc: netconf@ietf.org Subject: Re: [Netconf] New work: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Be conservative in what you send and liberal in what you receive. I do not think we should leave it up to each server to decide for itself what to return; we need to specify what is the correct behavior for compliance to the standard, so we have something that is interoperable. Will legacy devices already support this feature of a brand new standard? of course not. We should design the standard for interoperability, not to make all existing devices able to claim compliance based on their current CLI behavior. If an existing device has a CLI that already keeps track of whether values are explicitly set or defaults, then those devices have a leg up on meeting the netconf standard; those that do not do this in their CLI will need to add the capability in the netconf implementation. The client should be able to handle responses of any approach, because the client should be able to handle non-compliant responses without crashing. Are we trying to standardize things to work more interoperably in the future, or to mimic all of the non-interoperable choices made by vendors in the past? dbh > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Phil Shafer > Sent: Monday, August 25, 2008 12:37 PM > To: Balazs Lengyel > Cc: netconf@ietf.org > Subject: Re: [Netconf] New work: with-defaults > > Balazs Lengyel writes: > >While I agree with the principle, some devices might not > store the difference > >between a leaf > >set to 5 explicitly and a leaf that only has a 5 as a > default value. (We have > >such devices :-( > > Many devices have mimiced IOS behavior in this regard, which is > part of the yang draft says: > > A NETCONF server that replies to a or request > MAY choose not to send the leaf element if its value is the > default value. > > I prefer (vastly) the "keep values explicitly set" behavior, so we > allow device to choose their own path. The client needs to be able > to handle devices that work both ways: > > Thus, a client that receives an for a or > request, must be prepared to handle the case that > a leaf node with a default value is not present in the XML. In > this case, the value used by the server is known to be the > default value. > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Aug 26 12:46:13 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D9E3A6A60; Tue, 26 Aug 2008 12:46:13 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B99D3A6849 for ; Tue, 26 Aug 2008 12:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPcU-ulsh7aX for ; Tue, 26 Aug 2008 12:46:09 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 64AB03A696B for ; Tue, 26 Aug 2008 12:46:09 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B35BB20491; Tue, 26 Aug 2008 21:45:53 +0200 (CEST) X-AuditID: c1b4fb3c-ae8cfbb0000015b5-05-48b45d714bb7 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 890152000C; Tue, 26 Aug 2008 21:45:53 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 21:45:53 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 21:45:52 +0200 Message-ID: <48B45D4D.2020907@ericsson.com> Date: Tue, 26 Aug 2008 21:45:17 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David B Harrington References: <48B2D9F0.5010507@ericsson.com> <200808251637.m7PGb0pk058148@idle.juniper.net> <025c01c907b3$7765f200$0600a8c0@china.huawei.com> In-Reply-To: <025c01c907b3$7765f200$0600a8c0@china.huawei.com> X-OriginalArrivalTime: 26 Aug 2008 19:45:52.0922 (UTC) FILETIME=[593987A0:01C907B4] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] New work: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello David, Interoperability is certainly a goal. However NETCONF will usually be fitted on nodes that already exist. So if we require them to change their existing datastore design (adding a bit for each leaf setBymanager { boolean} ), then we certainly raise the cost of NETCONF implementation. Balazs David B Harrington wrote: > Hi, > > Be conservative in what you send and liberal in what you receive. > > I do not think we should leave it up to each server to decide for > itself what to return; we need to specify what is the correct behavior > for compliance to the standard, so we have something that is > interoperable. > > Will legacy devices already support this feature of a brand new > standard? of course not. We should design the standard for > interoperability, not to make all existing devicFrom netconf-bounces@ietf.org Tue Aug 26 12:46:13 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D9E3A6A60; Tue, 26 Aug 2008 12:46:13 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B99D3A6849 for ; Tue, 26 Aug 2008 12:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPcU-ulsh7aX for ; Tue, 26 Aug 2008 12:46:09 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 64AB03A696B for ; Tue, 26 Aug 2008 12:46:09 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B35BB20491; Tue, 26 Aug 2008 21:45:53 +0200 (CEST) X-AuditID: c1b4fb3c-ae8cfbb0000015b5-05-48b45d714bb7 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 890152000C; Tue, 26 Aug 2008 21:45:53 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 21:45:53 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 21:45:52 +0200 Message-ID: <48B45D4D.2020907@ericsson.com> Date: Tue, 26 Aug 2008 21:45:17 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David B Harrington References: <48B2D9F0.5010507@ericsson.com> <200808251637.m7PGb0pk058148@idle.juniper.net> <025c01c907b3$7765f200$0600a8c0@china.huawei.com> In-Reply-To: <025c01c907b3$7765f200$0600a8c0@china.huawei.com> X-OriginalArrivalTime: 26 Aug 2008 19:45:52.0922 (UTC) FILETIME=[593987A0:01C907B4] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] New work: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello David, Interoperability is certainly a goal. However NETCONF will usually be fitted on nodes that already exist. So if we require them to change their existing datastore design (adding a bit for each leaf setBymanager { boolean} ), then we certainly raise the cost of NETCONF implementation. Balazs David B Harrington wrote: > Hi, > > Be conservative in what you send and liberal in what you receive. > > I do not think we should leave it up to each server to decide for > itself what to return; we need to specify what is the correct behavior > for compliance to the standard, so we have something that is > interoperable. > > Will legacy devices already support this feature of a brand new > standard? of course not. We should design the standard for > interoperability, not to make all existing devices able to claim > compliance based on their current CLI behavior. If an existing device > has a CLI that already keeps track of whether values are explicitly > set or defaults, then those devices have a leg up on meeting the > netconf standard; those that do not do this in their CLI will need to > add the capability in the netconf implementation. > > The client should be able to handle responses of any approach, because > the client should be able to handle non-compliant responses without > crashing. > > Are we trying to standardize things to work more interoperably in the > future, or to mimic all of the non-interoperable choices made by > vendors in the past? > > dbh > >> -----Original Message----- >> From: netconf-bounces@ietf.org >> [mailto:netconf-bounces@ietf.org] On Behalf Of Phil Shafer >> Sent: Monday, August 25, 2008 12:37 PM >> To: Balazs Lengyel >> Cc: netconf@ietf.org >> Subject: Re: [Netconf] New work: with-defaults >> >> Balazs Lengyel writes: >>> While I agree with the principle, some devices might not >> store the difference >>> between a leaf >>> set to 5 explicitly and a leaf that only has a 5 as a >> default value. (We have >>> such devices :-( >> Many devices have mimiced IOS behavior in this regard, which is >> part of the yang draft says: >> >> A NETCONF server that replies to a or request >> MAY choose not to send the leaf element if its value is the >> default value. >> >> I prefer (vastly) the "keep values explicitly set" behavior, so we >> allow device to choose their own path. The client needs to be able >> to handle devices that work both ways: >> >> Thus, a client that receives an for a or >> request, must be prepared to handle the case that >> a leaf node with a default value is not present in the XML. In >> this case, the value used by the server is known to be the >> default value. >> >> Thanks, >> Phil >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf es able to claim > compliance based on their current CLI behavior. If an existing device > has a CLI that already keeps track of whether values are explicitly > set or defaults, then those devices have a leg up on meeting the > netconf standard; those that do not do this in their CLI will need to > add the capability in the netconf implementation. > > The client should be able to handle responses of any approach, because > the client should be able to handle non-compliant responses without > crashing. > > Are we trying to standardize things to work more interoperably in the > future, or to mimic all of the non-interoperable choices made by > vendors in the past? > > dbh > >> -----Original Message----- >> From: netconf-bounces@ietf.org >> [mailto:netconf-bounces@ietf.org] On Behalf Of Phil Shafer >> Sent: Monday, August 25, 2008 12:37 PM >> To: Balazs Lengyel >> Cc: netconf@ietf.org >> Subject: Re: [Netconf] New work: with-defaults >> >> Balazs Lengyel writes: >>> While I agree with the principle, some devices might not >> store the difference >>> between a leaf >>> set to 5 explicitly and a leaf that only has a 5 as a >> default value. (We have >>> such devices :-( >> Many devices have mimiced IOS behavior in this regard, which is >> part of the yang draft says: >> >> A NETCONF server that replies to a or request >> MAY choose not to send the leaf element if its value is the >> default value. >> >> I prefer (vastly) the "keep values explicitly set" behavior, so we >> allow device to choose their own path. The client needs to be able >> to handle devices that work both ways: >> >> Thus, a client that receives an for a or >> request, must be prepared to handle the case that >> a leaf node with a default value is not present in the XML. In >> this case, the value used by the server is known to be the >> default value. >> >> Thanks, >> Phil >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Aug 26 13:23:24 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803CF3A6B90; Tue, 26 Aug 2008 13:23:24 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4E33A6B40 for ; Tue, 26 Aug 2008 13:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, 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 xbHRuNfMBntc for ; Tue, 26 Aug 2008 13:23:22 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 7C0853A686B for ; Tue, 26 Aug 2008 13:23:22 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Tue, 26 Aug 2008 13:23:06 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Aug 2008 13:23:05 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Aug 2008 13:23:04 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 13:23: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 m7QKN3u55081; Tue, 26 Aug 2008 13:23:03 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7QKJODG091607; Tue, 26 Aug 2008 20:19:25 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808262019.m7QKJODG091607@idle.juniper.net> To: "David B Harrington" In-reply-to: <025c01c907b3$7765f200$0600a8c0@china.huawei.com> Date: Tue, 26 Aug 2008 16:19:24 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 Aug 2008 20:23:04.0320 (UTC) FILETIME=[8B3DD800:01C907B9] Cc: netconf@ietf.org Subject: Re: [Netconf] New work: 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "David B Harrington" writes: >Are we trying to standardize things to work more interoperably in the >future, or to mimic all of the non-interoperable choices made by >vendors in the past? I think we're trying to maximize market acceptance, allowing the large set of devices to use YANG (and YANG modules) as easily as possible in order to encourage people to use what we're making and avoid having an incredible standard that no one implements. The alternate theory is we're making a spec that minimizes the opportunity for vendors to decide that they will be forced (for economic reasons, meaning the cost of doing it the right way) to violate the spec in order to ship something they can call YANG/NETCONF. If a vendor can't implement a feature correctly without rototiling their entire code base, it's not going to happen. Yes, I'd love it to work the way my code works (save user-specified values even if they are the default), but we need to be flexible enough to embrace vendors that don't work that way. So the short answer is: If we don't deal with the present/past, we won't get to become the future. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Aug 26 13:23:24 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803CF3A6B90; Tue, 26 Aug 2008 13:23:24 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4E33A6B40 for ; Tue, 26 Aug 2008 13:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, 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 xbHRuNfMBntc for ; Tue, 26 Aug 2008 13:23:22 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 7C0853A686B for ; Tue, 26 Aug 2008 13:23:22 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Tue, 26 Aug 2008 13:23:06 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Aug 2008 13:23:05 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Aug 2008 13:23:04 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 13:23: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 m7QKN3u55081; Tue, 26 Aug 2008 13:23:03 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7QKJODG091607; Tue, 26 Aug 2008 20:19:25 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808262019.m7QKJODG091607@idle.juniper.net> To: "David B Harrington" In-reply-to: <025c01c907b3$7765f200$0600a8c0@china.huawei.com> Date: Tue, 26 Aug 2008 16:19:24 -0400 From: Phil Shafer X-OriginalArrivalTime: 26 Aug 2008 20:23:04.0320 (UTC) FILETIME=[8B3DD800:01C907B9] Cc: netconf@ietf.org Subject: Re: [Netconf] New work: 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "David B Harrington" writes: >Are we trying to standardize things to work more interoperably in the >future, or to mimic all of the non-interoperable choices made by >vendors in the past? I think we're trying to maximize market acceptance, allowing the large set of devices to use YANG (and YANG modules) as easily as possible in order to encourage people to use what we're making and avoid having an incredible standard that no one implements. The alternate theory is we're making a spec that minimizes the opportunity for vendors to decide that they will be forced (for economic reasons, meaning the cost of doing it the right way) to violate the spec in order to ship something they can call YANG/NETCONF. If a vendor can't implement a feature correctly without rototiling their entire code base, it's not going to happen. Yes, I'd love it to work the way my code works (save user-specified values even if they are the default), but we need to be flexible enough to embrace vendors that don't work that way. So the short answer is: If we don't deal with the present/past, we won't get to become the future. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Aug 26 16:00:31 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B5123A6C20; Tue, 26 Aug 2008 16:00:31 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 315383A6C20 for ; Tue, 26 Aug 2008 16:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 WhDNEextOMHo for ; Tue, 26 Aug 2008 16:00:29 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 1231B3A68C6 for ; Tue, 26 Aug 2008 16:00:29 -0700 (PDT) Received: (qmail 32232 invoked from network); 26 Aug 2008 22:59:44 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 26 Aug 2008 22:59:43 -0000 X-YMail-OSG: kdwI9M4VM1kNSqkk.MYCqUUUPIz.Z0AZvQWi8P8Ts3BgYGMALBB5wf5q5yoFRz4YljTHa2Kt2PweeeL2UynSXjXoeboU30e1tF0hyuLCuuRWJdgqBn_h21NxWbN9LV0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B48ADC.30408@netconfcentral.com> Date: Tue, 26 Aug 2008 15:59:40 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: David B Harrington References: <48B2D9F0.5010507@ericsson.com> <200808251637.m7PGb0pk058148@idle.juniper.net> <025c01c907b3$7765f200$0600a8c0@china.huawei.com> In-Reply-To: <025c01c907b3$7765f200$0600a8c0@china.huawei.com> Cc: netconf@ietf.org Subject: Re: [Netconf] New work: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org David B Harrington wrote: > Hi, > > Be conservative in what you send and liberal in what you receive. > > I do not think we should leave it up to each server to decide for > itself what to return; we need to specify what is the correct behavior > for compliance to the standard, so we have something that is > interoperable. > > Will legacy devices already support this feature of a brand new > standard? of course not. We should design the standard for > interoperability, not to make all existing devices able to claim > compliance based on their current CLI behavior. If an existing device > has a CLI that already keeps track of whether values are explicitly > set or defaults, then those devices have a leg up on meeting the > netconf standard; those that do not do this in their CLI will need to > add the capability in the netconf implementation. > > The client should be able to handle responses of any approach, because > the client should be able to handle non-compliant responses without > crashing. > > Are we trying to standardize things to work more interoperably in the > future, or to mimic all of the non-interoperable choices made by > vendors in the past? It has always been the 'NETCONF philosophy' to standardize what we can, and use capabilities to identify the things we cannot standardize. The 'with-defaults' feature itself does not seem to be the problem. If you support the capability, you will return everything is asked by the manager. This may be like vs. as the config target. We had no success forcing one camp to give in and say "we'll toss our code out and do it your way". And just like the vs. debate, if the manager knows which of the finite set of variants is supported, it can deal with the agent easily. I would prefer a standard solution, like you would. But I will settle for a standard way to figure out what the agent will do. IMO, the arguments against returning the defaults when asked by the agent are based on the outdated notion that bandwidth is expensive and memory is insanely expensive. I can buy a 1G stick of memory on eBay for $12, a gigE switch for $50. The idea that it is too much burden for a router to store these values seems absurd to me. > > dbh Andy > >> -----Original Message----- >> From: netconf-bounces@ietf.org >> [mailto:netconf-bounces@ietf.org] On Behalf Of Phil Shafer >> Sent: Monday, August 25, 2008 12:37 PM >> To: Balazs Lengyel >> Cc: netconf@ietf.org >> Subject: Re: [Netconf] New work: with-defaults >> >> Balazs Lengyel writes: >>> While I agree with the principle, some devices might not >> store the difference >>> between a leaf >>> set to 5 explicitly and a leaf that only has a 5 as a >> default value. (We have >>> such devices :-( >> Many devices have mimiced IOS behavior in this regard, which is >> part of the yang draft says: >> >> A NETCONF server that replies to a or request >> MAY choose not to send the leaf element if its value is the >> default value. >> >> I prefer (vastly) the "keep values explicitly set" behavior, so we >> allow device to choose their own path. The client needs to be able >> to handle devices that work both ways: >> >> Thus, a client that receives an for a or >> request, must be prepared to handle the case that >> a leaf node with a default value is not present in the XML. In >> this case, the value used by the server is known to be the >> default value. >> >> Thanks, >> Phil >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Aug 26 16:00:31 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B5123A6C20; Tue, 26 Aug 2008 16:00:31 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 315383A6C20 for ; Tue, 26 Aug 2008 16:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 WhDNEextOMHo for ; Tue, 26 Aug 2008 16:00:29 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 1231B3A68C6 for ; Tue, 26 Aug 2008 16:00:29 -0700 (PDT) Received: (qmail 32232 invoked from network); 26 Aug 2008 22:59:44 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 26 Aug 2008 22:59:43 -0000 X-YMail-OSG: kdwI9M4VM1kNSqkk.MYCqUUUPIz.Z0AZvQWi8P8Ts3BgYGMALBB5wf5q5yoFRz4YljTHa2Kt2PweeeL2UynSXjXoeboU30e1tF0hyuLCuuRWJdgqBn_h21NxWbN9LV0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B48ADC.30408@netconfcentral.com> Date: Tue, 26 Aug 2008 15:59:40 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: David B Harrington References: <48B2D9F0.5010507@ericsson.com> <200808251637.m7PGb0pk058148@idle.juniper.net> <025c01c907b3$7765f200$0600a8c0@china.huawei.com> In-Reply-To: <025c01c907b3$7765f200$0600a8c0@china.huawei.com> Cc: netconf@ietf.org Subject: Re: [Netconf] New work: 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org David B Harrington wrote: > Hi, > > Be conservative in what you send and liberal in what you receive. > > I do not think we should leave it up to each server to decide for > itself what to return; we need to specify what is the correct behavior > for compliance to the standard, so we have something that is > interoperable. > > Will legacy devices already support this feature of a brand new > standard? of course not. We should design the standard for > interoperability, not to make all existing devices able to claim > compliance based on their current CLI behavior. If an existing device > has a CLI that already keeps track of whether values are explicitly > set or defaults, then those devices have a leg up on meeting the > netconf standard; those that do not do this in their CLI will need to > add the capability in the netconf implementation. > > The client should be able to handle responses of any approach, because > the client should be able to handle non-compliant responses without > crashing. > > Are we trying to standardize things to work more interoperably in the > future, or to mimic all of the non-interoperable choices made by > vendors in the past? It has always been the 'NETCONF philosophy' to standardize what we can, and use capabilities to identify the things we cannot standardize. The 'with-defaults' feature itself does not seem to be the problem. If you support the capability, you will return everything is asked by the manager. This may be like vs. as the config target. We had no success forcing one camp to give in and say "we'll toss our code out and do it your way". And just like the vs. debate, if the manager knows which of the finite set of variants is supported, it can deal with the agent easily. I would prefer a standard solution, like you would. But I will settle for a standard way to figure out what the agent will do. IMO, the arguments against returning the defaults when asked by the agent are based on the outdated notion that bandwidth is expensive and memory is insanely expensive. I can buy a 1G stick of memory on eBay for $12, a gigE switch for $50. The idea that it is too much burden for a router to store these values seems absurd to me. > > dbh Andy > >> -----Original Message----- >> From: netconf-bounces@ietf.org >> [mailto:netconf-bounces@ietf.org] On Behalf Of Phil Shafer >> Sent: Monday, August 25, 2008 12:37 PM >> To: Balazs Lengyel >> Cc: netconf@ietf.org >> Subject: Re: [Netconf] New work: with-defaults >> >> Balazs Lengyel writes: >>> While I agree with the principle, some devices might not >> store the difference >>> between a leaf >>> set to 5 explicitly and a leaf that only has a 5 as a >> default value. (We have >>> such devices :-( >> Many devices have mimiced IOS behavior in this regard, which is >> part of the yang draft says: >> >> A NETCONF server that replies to a or request >> MAY choose not to send the leaf element if its value is the >> default value. >> >> I prefer (vastly) the "keep values explicitly set" behavior, so we >> allow device to choose their own path. The client needs to be able >> to handle devices that work both ways: >> >> Thus, a client that receives an for a or >> request, must be prepared to handle the case that >> a leaf node with a default value is not present in the XML. In >> this case, the value used by the server is known to be the >> default value. >> >> Thanks, >> Phil >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Aug 26 16:56:15 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EFD63A6C4B; Tue, 26 Aug 2008 16:56:15 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293283A6B89 for ; Tue, 26 Aug 2008 16:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.381 X-Spam-Level: X-Spam-Status: No, score=0.381 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_50=0.001, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QVxmF-S9gw6 for ; Tue, 26 Aug 2008 16:56:09 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 2C6883A695B for ; Tue, 26 Aug 2008 16:56:08 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 7687B980AF for ; Tue, 26 Aug 2008 16:55:35 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 2E10039A273 for ; Tue, 26 Aug 2008 16:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :subject:date:message-id:mime-version:content-type; s=wesmail; bh=n3JDGk+YKGose3pts0ZKVTLi9+8=; b=AnL304nVk9KEfnvfIT0J84uthNdz u1pD/MIk9JuOMila/nsFFTWmtmjgj4qFMKpLH76eO7VT5lD5hwJ/txf6MRGL30T/ d0dnKBuUbigwTcMXAR3vC6R2ow6DN5ck6NA8dudJS48rr42E6o24Es3vU21Q087g IJw6biKZS1w9Rig= Received: by wes.hardakers.net (Postfix, from userid 274) id 0162B39A293; Tue, 26 Aug 2008 16:55:34 -0700 (PDT) From: Wes Hardaker To: netconf@ietf.org Organization: Sparta Date: Tue, 26 Aug 2008 16:55:34 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Subject: [Netconf] evaluation of the partial-lock document X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org * My final thoughts and concerns on the partial-lock feature as a whole are in the last section of this... Netconf WG last call report on partial lock =========================================== Author: Wes Hardaker Date: 2008-08-26 16:50:09 PDT Table of Contents ================= 1 General Notes 2 Thoughts on: Partial locks don't cover non-existing nodes 3 section 2.1: "Note:" wording 4 section 2.1, starting with "As with most locking..." 5 Question about multiple locks from the same session... 6 Section 2.4.1.1: target: 7 Section 2.4.1.1: text change 8 Section 2.4.1.1: first example 9 Side thought: netconf documents all assume a particular data model 10 Section 2.4.1.1: 2nd to last paragraph: 11 Section 2.4.2: 12 Section 2.4.2, negative response: 13 Section 2.5 14 Section 3, second paragraph: first sentence needs ()s or commas 15 Comparison of xpath evaluated partial lock vs locked nodes 1 General Notes --------------- * Document is very well layed out and easy to understand. It flows well and is easy to read. * But... The English grammar could use some polishing in a few more places than I've listed here. + I'd recommend the authors hand it to someone that hasn't been involved in editing for a simple polishing pass. * My final thoughts and concerns on the partial-lock feature as a whole are in the last section of this... 2 Thoughts on: Partial locks don't cover non-existing nodes ----------------------------------------------------------- * (Section 2.4.1-ish) * note: can't lock a tree part that doesn't exist yet * There exists odd an usage case when a tree doesn't yet exist (empty configuration). E.G., I can't lock the users tree until at least 1 users/user exists. If I try to lock when no subelement exists then I believe I get an error back (I'm not even positive about this). Section 2.4.1 seems to indicate that it'll fail since at least one of the select sets MUST be non-empty. + The result is that you *must* create a single before you can lock the table, for example. IE a manager is expected to be able to perform and understand why it's doing the following odd sequence: - partial-lock => failure because it's empty. - create a joe - partial-lock => success - Edit users - unlock + This is just an odd error handling case that manegers will have to cope with and it only exists because of the inability to lock an empty tree. * Section 2.4.1.2 discusses this aspect of partial-locking, but the security implications may be that you don't have permission to lock a parent node of for exmaple. IE, You shouldn't have to take out lock on just because you want to lock (and you shouldn't have to create a user before you can lock the table). 3 section 2.1: "Note:" wording ------------------------------ * First sentence isn't a complete sentence * I'd argue this isn't just a "Note" but an interaction with another capability and probably should be spelled out more importantly than just as a "Note:" that implies it's just additional information. 4 section 2.1, starting with "As with most locking..." ------------------------------------------------------ * Change: * "parts of the configuration become dead-locked" => * "parts of the configuration *could* become dead-locked" 5 Question about multiple locks from the same session... -------------------------------------------------------- * Is it allowed? Doesn't say one way or another... * Consider: 1. lock with one partial nodes A and B 2. and then with another try to lock B and C 3. Do I get an error because B is locked (by me in this session)? 4. or now do I have multiple locks covering A, B and C? * I *think* I get an error? * If I do have A, B and C locked: + and then I release the lock + do I still have B and C locked with the second or just C (I'd assume B and C)? * The document discusses this ramification for but not really well for * It sort of implies an error further in 2.4.1.1 "If a lock is already held on any node..." 6 Section 2.4.1.1: target: -------------------------- * Wouldn't it be best to state directly: "a may only have one parameter?" 7 Section 2.4.1.1: text change ------------------------------ * "If the device supports the :xpath capability as well any valid" => * "If the device supports the :xpath capability *then* any valid" 8 Section 2.4.1.1: first example -------------------------------- * Shouldn't be within a scope? * The schema seems to indicate no * But it should (IMHO) if nothing else to match usage which does have a parameter. + (if memory serves this was discussed early on in netconf and it was agreed that all targets should be directly specified inside a named or similar parameter tag) 9 Side thought: netconf documents all assume a particular data model -------------------------------------------------------------------- * Is it just me, or should all the netconf documents be replaced once a real data model exists with real example nodes to use? * Right now all the examples give the impression that the example RPCs will work, when in actuality they won't match the real world data models. + EG: /interfaces/interface[Id='eth1'] 10 Section 2.4.1.1: 2nd to last paragraph: ------------------------------------------ * Explicitly spelling out an xpath failure is nice to understand. But in reality this should be more generic in order to handle failing on future select type expressions (xpath2) or other syntax errors. Maybe something like "search expression type not supported"? + What type of error do I get back for /users/user[name='Joe 11 Section 2.4.2: ----------------- * Nit: Replace "Example: Unlock" with "Example: Unlock a previously created lock" + or just remove: "Unlock" + The title just looks a touch odd as is (incomplete). 12 Section 2.4.2, negative response: ------------------------------------ * So there is no way to break a lock from a different session? Then what happens if a TCP connection drops according to the client (or is forced to drop) but the server hasn't realized it's closed? + Looks like kill-session is the solution based on later reading, but I'd suggest spelling it out here. + Requires access to the kill-session command to release a hung-lock. Possibly worth mentioning in the security expectations. 13 Section 2.5 -------------- * I'd spell out in no uncertain terms that any command that modifies a datastore will be blocked, and that "includes" the current list. The wording as is could be easily misinterpreted to read that the current list is all you need to worry about (which I know wasn't the intent). 14 Section 3, second paragraph: first sentence needs ()s or commas ------------------------------------------------------------------ around the lock types. 15 Comparison of xpath evaluated partial lock vs locked nodes ------------------------------------------------------------- * I'm not personally convienced still that locking existing nodes only is the best solution for partial locking. I know it's been debated a bunch in the past but I'm not even convienced there is consusus on the subject. I suspect that if you counted the number of folks that started an argument about it the numbers wouldn't point clearly to a consensus. Many of the arguments came at different times, which makes it hard to count. + That being said, letting this one go forward doesn't prohibit a different later solution. + I'm not convienced that locking nodes is cheaper to implement or execute than evaluating edits based on a memorized xpath solution. * Comparison: * XPATH eval: + easier to list in a "list of outstanding locks" table + storage cost is very small (a list of xpaths) + CPU usage is higher (An eval on every command is required) + I think it's more intuitive... There isn't an unknown "it's no longer locked because you deleted it" sudden surprise. * locking a list of nodes with a eval-once: + Lower CPU usage since it's a single xpath eval - Higher memory cost (need to memorize every locked node either through a list or a flag) - Usage complexity is much higher - Can't lock empty parent nodes - security ramifications require parent nodes for *everything* - deleted nodes can be recreated * This is most critical when manipulating ordered lists of things like access rules (eg, firewall rules) * I've seen real-world current discussions surrounding the need to put in a parent tree for all nodes *just* because of the partial-lock inability to lock a common set of nodes. The result of this type of partical lock means either: + data models will add extra tree nodes everywhere + Or they wont' and it'll turn out later they should have because of opreational needs for locking all the subnodes and it can't be done. - IE, it becomes critical to create a node to surround a list of firewall nodes. + I think it's worth spelling out this issue in the security considerations so that every data model ever created gets a otherwise-empty top node added above it so that it can be locked. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Aug 26 16:56:15 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EFD63A6C4B; Tue, 26 Aug 2008 16:56:15 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293283A6B89 for ; Tue, 26 Aug 2008 16:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.381 X-Spam-Level: X-Spam-Status: No, score=0.381 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_50=0.001, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QVxmF-S9gw6 for ; Tue, 26 Aug 2008 16:56:09 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 2C6883A695B for ; Tue, 26 Aug 2008 16:56:08 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 7687B980AF for ; Tue, 26 Aug 2008 16:55:35 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 2E10039A273 for ; Tue, 26 Aug 2008 16:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :subject:date:message-id:mime-version:content-type; s=wesmail; bh=n3JDGk+YKGose3pts0ZKVTLi9+8=; b=AnL304nVk9KEfnvfIT0J84uthNdz u1pD/MIk9JuOMila/nsFFTWmtmjgj4qFMKpLH76eO7VT5lD5hwJ/txf6MRGL30T/ d0dnKBuUbigwTcMXAR3vC6R2ow6DN5ck6NA8dudJS48rr42E6o24Es3vU21Q087g IJw6biKZS1w9Rig= Received: by wes.hardakers.net (Postfix, from userid 274) id 0162B39A293; Tue, 26 Aug 2008 16:55:34 -0700 (PDT) From: Wes Hardaker To: netconf@ietf.org Organization: Sparta Date: Tue, 26 Aug 2008 16:55:34 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Subject: [Netconf] evaluation of the partial-lock document X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org * My final thoughts and concerns on the partial-lock feature as a whole are in the last section of this... Netconf WG last call report on partial lock =========================================== Author: Wes Hardaker Date: 2008-08-26 16:50:09 PDT Table of Contents ================= 1 General Notes 2 Thoughts on: Partial locks don't cover non-existing nodes 3 section 2.1: "Note:" wording 4 section 2.1, starting with "As with most locking..." 5 Question about multiple locks from the same session... 6 Section 2.4.1.1: target: 7 Section 2.4.1.1: text change 8 Section 2.4.1.1: first example 9 Side thought: netconf documents all assume a particular data model 10 Section 2.4.1.1: 2nd to last paragraph: 11 Section 2.4.2: 12 Section 2.4.2, negative response: 13 Section 2.5 14 Section 3, second paragraph: first sentence needs ()s or commas 15 Comparison of xpath evaluated partial lock vs locked nodes 1 General Notes --------------- * Document is very well layed out and easy to understand. It flows well and is easy to read. * But... The English grammar could use some polishing in a few more places than I've listed here. + I'd recommend the authors hand it to someone that hasn't been involved in editing for a simple polishing pass. * My final thoughts and concerns on the partial-lock feature as a whole are in the last section of this... 2 Thoughts on: Partial locks don't cover non-existing nodes ----------------------------------------------------------- * (Section 2.4.1-ish) * note: can't lock a tree part that doesn't exist yet * There exists odd an usage case when a tree doesn't yet exist (empty configuration). E.G., I can't lock the users tree until at least 1 users/user exists. If I try to lock when no subelement exists then I believe I get an error back (I'm not even positive about this). Section 2.4.1 seems to indicate that it'll fail since at least one of the select sets MUST be non-empty. + The result is that you *must* create a single before you can lock the table, for example. IE a manager is expected to be able to perform and understand why it's doing the following odd sequence: - partial-lock => failure because it's empty. - create a joe - partial-lock => success - Edit users - unlock + This is just an odd error handling case that manegers will have to cope with and it only exists because of the inability to lock an empty tree. * Section 2.4.1.2 discusses this aspect of partial-locking, but the security implications may be that you don't have permission to lock a parent node of for exmaple. IE, You shouldn't have to take out lock on just because you want to lock (and you shouldn't have to create a user before you can lock the table). 3 section 2.1: "Note:" wording ------------------------------ * First sentence isn't a complete sentence * I'd argue this isn't just a "Note" but an interaction with another capability and probably should be spelled out more importantly than just as a "Note:" that implies it's just additional information. 4 section 2.1, starting with "As with most locking..." ------------------------------------------------------ * Change: * "parts of the configuration become dead-locked" => * "parts of the configuration *could* become dead-locked" 5 Question about multiple locks from the same session... -------------------------------------------------------- * Is it allowed? Doesn't say one way or another... * Consider: 1. lock with one partial nodes A and B 2. and then with another try to lock B and C 3. Do I get an error because B is locked (by me in this session)? 4. or now do I have multiple locks covering A, B and C? * I *think* I get an error? * If I do have A, B and C locked: + and then I release the lock + do I still have B and C locked with the second or just C (I'd assume B and C)? * The document discusses this ramification for but not really well for * It sort of implies an error further in 2.4.1.1 "If a lock is already held on any node..." 6 Section 2.4.1.1: target: -------------------------- * Wouldn't it be best to state directly: "a may only have one parameter?" 7 Section 2.4.1.1: text change ------------------------------ * "If the device supports the :xpath capability as well any valid" => * "If the device supports the :xpath capability *then* any valid" 8 Section 2.4.1.1: first example -------------------------------- * Shouldn't be within a scope? * The schema seems to indicate no * But it should (IMHO) if nothing else to match usage which does have a parameter. + (if memory serves this was discussed early on in netconf and it was agreed that all targets should be directly specified inside a named or similar parameter tag) 9 Side thought: netconf documents all assume a particular data model -------------------------------------------------------------------- * Is it just me, or should all the netconf documents be replaced once a real data model exists with real example nodes to use? * Right now all the examples give the impression that the example RPCs will work, when in actuality they won't match the real world data models. + EG: /interfaces/interface[Id='eth1'] 10 Section 2.4.1.1: 2nd to last paragraph: ------------------------------------------ * Explicitly spelling out an xpath failure is nice to understand. But in reality this should be more generic in order to handle failing on future select type expressions (xpath2) or other syntax errors. Maybe something like "search expression type not supported"? + What type of error do I get back for /users/user[name='Joe 11 Section 2.4.2: ----------------- * Nit: Replace "Example: Unlock" with "Example: Unlock a previously created lock" + or just remove: "Unlock" + The title just looks a touch odd as is (incomplete). 12 Section 2.4.2, negative response: ------------------------------------ * So there is no way to break a lock from a different session? Then what happens if a TCP connection drops according to the client (or is forced to drop) but the server hasn't realized it's closed? + Looks like kill-session is the solution based on later reading, but I'd suggest spelling it out here. + Requires access to the kill-session command to release a hung-lock. Possibly worth mentioning in the security expectations. 13 Section 2.5 -------------- * I'd spell out in no uncertain terms that any command that modifies a datastore will be blocked, and that "includes" the current list. The wording as is could be easily misinterpreted to read that the current list is all you need to worry about (which I know wasn't the intent). 14 Section 3, second paragraph: first sentence needs ()s or commas ------------------------------------------------------------------ around the lock types. 15 Comparison of xpath evaluated partial lock vs locked nodes ------------------------------------------------------------- * I'm not personally convienced still that locking existing nodes only is the best solution for partial locking. I know it's been debated a bunch in the past but I'm not even convienced there is consusus on the subject. I suspect that if you counted the number of folks that started an argument about it the numbers wouldn't point clearly to a consensus. Many of the arguments came at different times, which makes it hard to count. + That being said, letting this one go forward doesn't prohibit a different later solution. + I'm not convienced that locking nodes is cheaper to implement or execute than evaluating edits based on a memorized xpath solution. * Comparison: * XPATH eval: + easier to list in a "list of outstanding locks" table + storage cost is very small (a list of xpaths) + CPU usage is higher (An eval on every command is required) + I think it's more intuitive... There isn't an unknown "it's no longer locked because you deleted it" sudden surprise. * locking a list of nodes with a eval-once: + Lower CPU usage since it's a single xpath eval - Higher memory cost (need to memorize every locked node either through a list or a flag) - Usage complexity is much higher - Can't lock empty parent nodes - security ramifications require parent nodes for *everything* - deleted nodes can be recreated * This is most critical when manipulating ordered lists of things like access rules (eg, firewall rules) * I've seen real-world current discussions surrounding the need to put in a parent tree for all nodes *just* because of the partial-lock inability to lock a common set of nodes. The result of this type of partical lock means either: + data models will add extra tree nodes everywhere + Or they wont' and it'll turn out later they should have because of opreational needs for locking all the subnodes and it can't be done. - IE, it becomes critical to create a node to surround a list of firewall nodes. + I think it's worth spelling out this issue in the security considerations so that every data model ever created gets a otherwise-empty top node added above it so that it can be locked. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Aug 27 01:04:55 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9457E3A6A46; Wed, 27 Aug 2008 01:04:55 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E275B3A685C for ; Wed, 27 Aug 2008 01:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEexsZMAPkPN for ; Wed, 27 Aug 2008 01:04:53 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 1B8063A68BD for ; Wed, 27 Aug 2008 01:04:53 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7BEA320695 for ; Wed, 27 Aug 2008 10:04:45 +0200 (CEST) X-AuditID: c1b4fb3e-a5e7fbb000007a96-5b-48b50a9d5752 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 637A720170 for ; Wed, 27 Aug 2008 10:04:45 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Aug 2008 10:04:44 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Aug 2008 10:04:44 +0200 Message-ID: <48B50A7A.8040002@ericsson.com> Date: Wed, 27 Aug 2008 10:04:10 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf mailing list X-OriginalArrivalTime: 27 Aug 2008 08:04:44.0371 (UTC) FILETIME=[90D3D230:01C9081B] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] with-defaults draft submitted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, I submitted the 00 version of the WITH-DEFAULTS draft. http://tools.ietf.org/id/draft-bierman-netconf-with-defaults-00.txt I would like to have it accepted as a NETCONF WG item. If you agree that it is important to define this capability please support it, even if you are unhappy with the exact solution, which can be debated/changed/agreed in the WG. During this work we also intend to take into account whatever the NETMOD group says about the topic. Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Aug 27 01:04:55 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9457E3A6A46; Wed, 27 Aug 2008 01:04:55 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E275B3A685C for ; Wed, 27 Aug 2008 01:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEexsZMAPkPN for ; Wed, 27 Aug 2008 01:04:53 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 1B8063A68BD for ; Wed, 27 Aug 2008 01:04:53 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7BEA320695 for ; Wed, 27 Aug 2008 10:04:45 +0200 (CEST) X-AuditID: c1b4fb3e-a5e7fbb000007a96-5b-48b50a9d5752 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 637A720170 for ; Wed, 27 Aug 2008 10:04:45 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Aug 2008 10:04:44 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Aug 2008 10:04:44 +0200 Message-ID: <48B50A7A.8040002@ericsson.com> Date: Wed, 27 Aug 2008 10:04:10 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf mailing list X-OriginalArrivalTime: 27 Aug 2008 08:04:44.0371 (UTC) FILETIME=[90D3D230:01C9081B] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] with-defaults draft submitted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, I submitted the 00 version of the WITH-DEFAULTS draft. http://tools.ietf.org/id/draft-bierman-netconf-with-defaults-00.txt I would like to have it accepted as a NETCONF WG item. If you agree that it is important to define this capability please support it, even if you are unhappy with the exact solution, which can be debated/changed/agreed in the WG. During this work we also intend to take into account whatever the NETMOD group says about the topic. Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Aug 27 02:34:14 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F1B3A6C70; Wed, 27 Aug 2008 02:34:14 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 571EA3A6C70 for ; Wed, 27 Aug 2008 02:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=0.779, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhNkBmVE+jSS for ; Wed, 27 Aug 2008 02:34:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 19EF13A6A08 for ; Wed, 27 Aug 2008 02:34:12 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 796C3C006D; Wed, 27 Aug 2008 11:33:53 +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 hy9SftX8TeOL; Wed, 27 Aug 2008 11:33:44 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D50A8C0069; Wed, 27 Aug 2008 11:33:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5978A6B0E9E; Wed, 27 Aug 2008 11:33:44 +0200 (CEST) Date: Wed, 27 Aug 2008 11:33:44 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20080827093344.GA29025@elstar.local> Mail-Followup-To: Balazs Lengyel , netconf mailing list References: <48B50A7A.8040002@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48B50A7A.8040002@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf mailing list Subject: Re: [Netconf] with-defaults draft submitted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Wed, Aug 27, 2008 at 10:04:10AM +0200, Balazs Lengyel wrote: > I submitted the 00 version of the WITH-DEFAULTS draft. > http://tools.ietf.org/id/draft-bierman-netconf-with-defaults-00.txt > > I would like to have it accepted as a NETCONF WG item. If you agree > that it is important to define this capability please support it, > even if you are unhappy with the exact solution, which can be > debated/changed/agreed in the WG. During this work we also intend to > take into account whatever the NETMOD group says about the topic. I support this document becoming a WG work item. Two comments from a quick read: - I suggest to add text to the motivation that says that suppressing / enabling defaults enables humans to better understand what is part of the explicit config of a device and what is just defaults. Right now, the motivation talks more about technical resources (bandwidth and CPU consumption aspects) but I am much more concerned about human resources (lots of defaults can hide the real config). - Considering section 7.2, what I really like to have is "all" and "explicit" - I do not really care that much about "trim". /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Aug 27 02:34:14 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F1B3A6C70; Wed, 27 Aug 2008 02:34:14 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 571EA3A6C70 for ; Wed, 27 Aug 2008 02:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=0.779, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhNkBmVE+jSS for ; Wed, 27 Aug 2008 02:34:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 19EF13A6A08 for ; Wed, 27 Aug 2008 02:34:12 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 796C3C006D; Wed, 27 Aug 2008 11:33:53 +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 hy9SftX8TeOL; Wed, 27 Aug 2008 11:33:44 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D50A8C0069; Wed, 27 Aug 2008 11:33:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5978A6B0E9E; Wed, 27 Aug 2008 11:33:44 +0200 (CEST) Date: Wed, 27 Aug 2008 11:33:44 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20080827093344.GA29025@elstar.local> Mail-Followup-To: Balazs Lengyel , netconf mailing list References: <48B50A7A.8040002@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48B50A7A.8040002@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf mailing list Subject: Re: [Netconf] with-defaults draft submitted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Wed, Aug 27, 2008 at 10:04:10AM +0200, Balazs Lengyel wrote: > I submitted the 00 version of the WITH-DEFAULTS draft. > http://tools.ietf.org/id/draft-bierman-netconf-with-defaults-00.txt > > I would like to have it accepted as a NETCONF WG item. If you agree > that it is important to define this capability please support it, > even if you are unhappy with the exact solution, which can be > debated/changed/agreed in the WG. During this work we also intend to > take into account whatever the NETMOD group says about the topic. I support this document becoming a WG work item. Two comments from a quick read: - I suggest to add text to the motivation that says that suppressing / enabling defaults enables humans to better understand what is part of the explicit config of a device and what is just defaults. Right now, the motivation talks more about technical resources (bandwidth and CPU consumption aspects) but I am much more concerned about human resources (lots of defaults can hide the real config). - Considering section 7.2, what I really like to have is "all" and "explicit" - I do not really care that much about "trim". /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Aug 27 07:28:37 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FEA33A6B21; Wed, 27 Aug 2008 07:28:37 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B151F28C1E1 for ; Wed, 27 Aug 2008 07:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 0LshI7+f6y6b for ; Wed, 27 Aug 2008 07:28:32 -0700 (PDT) Received: from chip3og61.obsmtp.com (chip3og61.obsmtp.com [64.18.14.187]) by core3.amsl.com (Postfix) with ESMTP id 3AAE03A67B0 for ; Wed, 27 Aug 2008 07:28:32 -0700 (PDT) Received: from source ([66.129.228.6]) by chip3ob61.postini.com ([64.18.6.12]) with SMTP; Wed, 27 Aug 2008 07:28:33 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 07:23:15 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 07:23:14 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 07:17:59 -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 m7REHwu99298; Wed, 27 Aug 2008 07:17:58 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7REEO1d098491; Wed, 27 Aug 2008 14:14:24 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808271414.m7REEO1d098491@idle.juniper.net> To: Balazs Lengyel In-reply-to: <48B50A7A.8040002@ericsson.com> Date: Wed, 27 Aug 2008 10:14:23 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2008 14:17:59.0259 (UTC) FILETIME=[B5388AB0:01C9084F] Cc: netconf mailing list Subject: Re: [Netconf] with-defaults draft submitted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel writes: >http://tools.ietf.org/id/draft-bierman-netconf-with-defaults-00.txt I support this work becoming a WG item. Comments: > The NETCONF protocol defines ways to read configuration data from a > NETCONF agent. Part of this data is not set by the NETCONF manager, > but rather set to a default value by the NETCONF agent. Remember that default values may never be "set". It's an implementation issue when and how the default mechanism works. > Is is often not useful for network operators to view all s/Is/It/ > these default values. It is usually more interesting to view just > the parameters which have been explicitly set by the network > operator. Make clear you are talking about human operators. > However there are perfectly valid use-cases when a NETCONFrom netconf-bounces@ietf.org Wed Aug 27 07:28:37 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FEA33A6B21; Wed, 27 Aug 2008 07:28:37 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B151F28C1E1 for ; Wed, 27 Aug 2008 07:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 0LshI7+f6y6b for ; Wed, 27 Aug 2008 07:28:32 -0700 (PDT) Received: from chip3og61.obsmtp.com (chip3og61.obsmtp.com [64.18.14.187]) by core3.amsl.com (Postfix) with ESMTP id 3AAE03A67B0 for ; Wed, 27 Aug 2008 07:28:32 -0700 (PDT) Received: from source ([66.129.228.6]) by chip3ob61.postini.com ([64.18.6.12]) with SMTP; Wed, 27 Aug 2008 07:28:33 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 07:23:15 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 07:23:14 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 07:17:59 -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 m7REHwu99298; Wed, 27 Aug 2008 07:17:58 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m7REEO1d098491; Wed, 27 Aug 2008 14:14:24 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200808271414.m7REEO1d098491@idle.juniper.net> To: Balazs Lengyel In-reply-to: <48B50A7A.8040002@ericsson.com> Date: Wed, 27 Aug 2008 10:14:23 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Aug 2008 14:17:59.0259 (UTC) FILETIME=[B5388AB0:01C9084F] Cc: netconf mailing list Subject: Re: [Netconf] with-defaults draft submitted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel writes: >http://tools.ietf.org/id/draft-bierman-netconf-with-defaults-00.txt I support this work becoming a WG item. Comments: > The NETCONF protocol defines ways to read configuration data from a > NETCONF agent. Part of this data is not set by the NETCONF manager, > but rather set to a default value by the NETCONF agent. Remember that default values may never be "set". It's an implementation issue when and how the default mechanism works. > Is is often not useful for network operators to view all s/Is/It/ > these default values. It is usually more interesting to view just > the parameters which have been explicitly set by the network > operator. Make clear you are talking about human operators. > However there are perfectly valid use-cases when a F manager > will need the default data from the node. Documentation about > default values is often unreliable or unavailable. Hopefully YANG will help eliminate this problem, allowing apps to know the fixed values for defaults. with-defaults will not solve the problem of making something with an unknown value because you don't know the default. Waiting until after you made it to know what you made isn't a workable solution. > Some management > applications might not have the capabilities to correctly parse and > interpret formal data models. Human users might want to understand > the received data without extensive consultation of the > documentation. In all theses cases the NETCONF manager will need s/theses/these/ > default data as part of the NETCONF rpc reply messages. >... > o Default data: Data that is set by the NETCONF agent whenever the > NETCONF manager does not provide a specific value for the relevant > data item. In the context of this document only configuration > data is considered, state data is excluded. See previous comment re: "data that is set" > The NETCONF > agent MUST also indicate it's default behavior, whether it sends > default data in the absence of any specific request from the NETCONF > manager. Do we need this feature? Can it simply default to "off"? Isn't it a pain to check the state before knowing you can turn it off? > The identifier MAY have a second parameter indicating how it treats > explicitly set default data. If the explicit-default parameter is > set to "unrecognized" the agent MUST treat explicitly set default > data as normal default data. If the parameter is set to recognized > this means that such data is not treated as default data. All other > values for the parameter or a missing parameter is handled as the > value unrecognized. > > urn:ietf:params:netconf:capability:with-defaults?default=false& > explicit-default=recognized Is there a more suitable term than "recognized"? Even "true" seems more clear. > A new 'with-defaults' XML attribute is used to control the generation > of default data. If the 'with-defaults' attribute is present in the > element, of the affected operations, the agent will use it's > value to control whether default data is returned in the NETCONF rpc > reply messages. I strongly dislike putting this as an attribute on : 1) It's a horrible precedent. Imagine every capability defining an attribute instead of modifying the proper operations. will become a dumping ground. 2) with-defaults isn't a generic attribute, but applies to a specific set of operations. Better to have it ties directly to those operations via a new element within their arguments (in YANG-speak). The list of affected operations is short enough that this is a simple solution: > Affected operations: > o > o > o Putting in on the is like making it an argument to every RPC but ignoring it for all but these three. 3) In YANG, this capability would be an augmentation of the input arguments to those three operations. There's no mechanism in YANG to address adding an attribute to . > Index clause components are not subject to default suppression. "index clause"? Is that snmp-speak? > If > an element within the configuration database is considered to be part > of a key, and represents one of the naming components for a > conceptual data structure which allows multiple named instances of an > ancestor node, then this element is never suppressed, regardless of > the value of the 'with-defaults' attribute. Keys don't have default values, so this isn't really an issue. > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > Should be: will need the default data from the node. Documentation about > default values is often unreliable or unavailable. Hopefully YANG will help eliminate this problem, allowing apps to know the fixed values for defaults. with-defaults will not solve the problem of making something with an unknown value because you don't know the default. Waiting until after you made it to know what you made isn't a workable solution. > Some management > applications might not have the capabilities to correctly parse and > interpret formal data models. Human users might want to understand > the received data without extensive consultation of the > documentation. In all theses cases the NETCONF manager will need s/theses/these/ > default data as part of the NETCONF rpc reply messages. >... > o Default data: Data that is set by the NETCONF agent whenever the > NETCONF manager does not provide a specific value for the relevant > data item. In the context of this document only configuration > data is considered, state data is excluded. See previous comment re: "data that is set" > The NETCONF > agent MUST also indicate it's default behavior, whether it sends > default data in the absence of any specific request from the NETCONF > manager. Do we need this feature? Can it simply default to "off"? Isn't it a pain to check the state before knowing you can turn it off? > The identifier MAY have a second parameter indicating how it treats > explicitly set default data. If the explicit-default parameter is > set to "unrecognized" the agent MUST treat explicitly set default > data as normal default data. If the parameter is set to recognized > this means that such data is not treated as default data. All other > values for the parameter or a missing parameter is handled as the > value unrecognized. > > urn:ietf:params:netconf:capability:with-defaults?default=false& > explicit-default=recognized Is there a more suitable term than "recognized"? Even "true" seems more clear. > A new 'with-defaults' XML attribute is used to control the generation > of default data. If the 'with-defaults' attribute is present in the > element, of the affected operations, the agent will use it's > value to control whether default data is returned in the NETCONF rpc > reply messages. I strongly dislike putting this as an attribute on : 1) It's a horrible precedent. Imagine every capability defining an attribute instead of modifying the proper operations. will become a dumping ground. 2) with-defaults isn't a generic attribute, but applies to a specific set of operations. Better to have it ties directly to those operations via a new element within their arguments (in YANG-speak). The list of affected operations is short enough that this is a simple solution: > Affected operations: > o > o > o Putting in on the is like making it an argument to every RPC but ignoring it for all but these three. 3) In YANG, this capability would be an augmentation of the input arguments to those three operations. There's no mechanism in YANG to address adding an attribute to . > Index clause components are not subject to default suppression. "index clause"? Is that snmp-speak? > If > an element within the configuration database is considered to be part > of a key, and represents one of the naming components for a > conceptual data structure which allows multiple named instances of an > ancestor node, then this element is never suppressed, regardless of > the value of the 'with-defaults' attribute. Keys don't have default values, so this isn't really an issue. > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > Should be: false >7.1. Augmenting the base RPCs > > Instead of using an attribute on the RPC element we could "augment" > the relevant NETCONF operations with an extra XML element with a > similar meaning. Coooool....... > Pro: parameters on RPC are for vendor extensions. We should not put > standard stuff there. See other Pros above. > Contra: Some people might consider this a violation of [RFC4741] as > the XSD does not allow adding new elements. As there is no NETCONF > YAM (at least not yet), what do we actually augment? Also there are > multiple ways of defining RFC4741 in YANG. The description will be > perfectly clear, but it can never be fed into YANG tools. If you see this as a violation, you are condemning all future changes to base operations to the same fate. I'd say declare this lack of flexibility in 4741's XSD a bug and fix it there. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf xmlns:wdef="urn:whatever:netconf:with-defaults" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> false >7.1. Augmenting the base RPCs > > Instead of using an attribute on the RPC element we could "augment" > the relevant NETCONF operations with an extra XML element with a > similar meaning. Coooool....... > Pro: parameters on RPC are for vendor extensions. We should not put > standard stuff there. See other Pros above. > Contra: Some people might consider this a violation of [RFC4741] as > the XSD does not allow adding new elements. As there is no NETCONF > YAM (at least not yet), what do we actually augment? Also there are > multiple ways of defining RFC4741 in YANG. The description will be > perfectly clear, but it can never be fed into YANG tools. If you see this as a violation, you are condemning all future changes to base operations to the same fate. I'd say declare this lack of flexibility in 4741's XSD a bug and fix it there. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 28 00:07:48 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F24A03A6891; Thu, 28 Aug 2008 00:07:47 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8923A6891 for ; Thu, 28 Aug 2008 00:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[AWL=0.744, 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 3+zFweOJ20Xt for ; Thu, 28 Aug 2008 00:07: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 9567B3A6851 for ; Thu, 28 Aug 2008 00:07:45 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 545B976C4DE; Thu, 28 Aug 2008 09:07:47 +0200 (CEST) Date: Thu, 28 Aug 2008 09:08:05 +0200 (CEST) Message-Id: <20080828.090805.254804201.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <48B50A7A.8040002@ericsson.com> References: <48B50A7A.8040002@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] with-defaults draft submitted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel wrote: > Hello, > I submitted the 00 version of the WITH-DEFAULTS draft. > http://tools.ietf.org/id/draft-bierman-netconf-with-defaults-00.txt > > I would like to have it accepted as a NETCONF WG item. If you agree > that it is important to define this capability please support it I support this work. Some comments: o Section 1. Another reason for not sending defaults is that if you take a config backup and later restore it, you don't want all the defaults to be explicitly set. [with your terminology; when explicit-defaults=unrecongnized] o 2.3 & 5 The capability URIs do not match. o Open issue 7.1 I agree w/ Phil that the correct solution is to add a parameter to the existing rpcs. Even though this is strictly not allowed by the XSD in RFC 4741, I think the idea is that capabilities are allowed to "augment" existing operations. o Open issue 7.2 I prefer your current solution with 'explicit-default' over making with-defaults have three values. Your solution makes it clear what the box really does. Nits: -------------------- s/it's/its/g -------------------- > It is not defined in [RFC4741] whether default data is part of the > datastore/data model, or if it meta data that influences the behavior ^^^^^^^^^^^^^ > of the NETCONF server device but is not actually part of the > datastore. -------------------- > The identifier MAY have a second parameter indicating how it treats > explicitly set default data. s/it/the NETCONF agent/ -------------------- s/effected/affected on several places -------------------- 1.1.2. says that "agent" and "manager" are defined in RFC 4741. They are not really defined there, and RFC 4741 uses the terms "client" (32) and "server" (59) more than "manager" (4) and "agent" (1). -------------------- /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 28 00:07:48 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F24A03A6891; Thu, 28 Aug 2008 00:07:47 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8923A6891 for ; Thu, 28 Aug 2008 00:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[AWL=0.744, 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 3+zFweOJ20Xt for ; Thu, 28 Aug 2008 00:07: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 9567B3A6851 for ; Thu, 28 Aug 2008 00:07:45 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 545B976C4DE; Thu, 28 Aug 2008 09:07:47 +0200 (CEST) Date: Thu, 28 Aug 2008 09:08:05 +0200 (CEST) Message-Id: <20080828.090805.254804201.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <48B50A7A.8040002@ericsson.com> References: <48B50A7A.8040002@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] with-defaults draft submitted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel wrote: > Hello, > I submitted the 00 version of the WITH-DEFAULTS draft. > http://tools.ietf.org/id/draft-bierman-netconf-with-defaults-00.txt > > I would like to have it accepted as a NETCONF WG item. If you agree > that it is important to define this capability please support it I support this work. Some comments: o Section 1. Another reason for not sending defaults is that if you take a config backup and later restore it, you don't want all the defaults to be explicitly set. [with your terminology; when explicit-defaults=unrecongnized] o 2.3 & 5 The capability URIs do not match. o Open issue 7.1 I agree w/ Phil that the correct solution is to add a parameter to the existing rpcs. Even though this is strictly not allowed by the XSD in RFC 4741, I think the idea is that capabilities are allowed to "augment" existing operations. o Open issue 7.2 I prefer your current solution with 'explicit-default' over making with-defaults have three values. Your solution makes it clear what the box really does. Nits: -------------------- s/it's/its/g -------------------- > It is not defined in [RFC4741] whether default data is part of the > datastore/data model, or if it meta data that influences the behavior ^^^^^^^^^^^^^ > of the NETCONF server device but is not actually part of the > datastore. -------------------- > The identifier MAY have a second parameter indicating how it treats > explicitly set default data. s/it/the NETCONF agent/ -------------------- s/effected/affected on several places -------------------- 1.1.2. says that "agent" and "manager" are defined in RFC 4741. They are not really defined there, and RFC 4741 uses the terms "client" (32) and "server" (59) more than "manager" (4) and "agent" (1). -------------------- /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 28 05:54:32 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 853073A6C85; Thu, 28 Aug 2008 05:54:32 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5212C28C0EE for ; Thu, 28 Aug 2008 05:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tKDceBBqmKr for ; Thu, 28 Aug 2008 05:54:30 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 754F63A680F for ; Thu, 28 Aug 2008 05:54:30 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 08ABE20A11 for ; Thu, 28 Aug 2008 14:26:47 +0200 (CEST) X-AuditID: c1b4fb3c-ae0cebb0000015b5-96-48b69986f574 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E84C320A01 for ; Thu, 28 Aug 2008 14:26:46 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 14:26:46 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 14:26:46 +0200 From: David Partain Organization: Ericsson AB To: netconf@ietf.org Date: Thu, 28 Aug 2008 14:26:45 +0200 User-Agent: KMail/1.9.9 References: <48B50A7A.8040002@ericsson.com> <20080828.090805.254804201.mbj@tail-f.com> In-Reply-To: <20080828.090805.254804201.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808281426.45930.david.partain@ericsson.com> X-OriginalArrivalTime: 28 Aug 2008 12:26:46.0073 (UTC) FILETIME=[561AEA90:01C90909] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] with-defaults draft submitted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I certainly support the NETCONF working group taking on this work and starting from draft-bierman-netconf-with-defaults-00.txt Cheers, David _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 28 05:54:32 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 853073A6C85; Thu, 28 Aug 2008 05:54:32 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5212C28C0EE for ; Thu, 28 Aug 2008 05:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tKDceBBqmKr for ; Thu, 28 Aug 2008 05:54:30 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 754F63A680F for ; Thu, 28 Aug 2008 05:54:30 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 08ABE20A11 for ; Thu, 28 Aug 2008 14:26:47 +0200 (CEST) X-AuditID: c1b4fb3c-ae0cebb0000015b5-96-48b69986f574 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E84C320A01 for ; Thu, 28 Aug 2008 14:26:46 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 14:26:46 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 14:26:46 +0200 From: David Partain Organization: Ericsson AB To: netconf@ietf.org Date: Thu, 28 Aug 2008 14:26:45 +0200 User-Agent: KMail/1.9.9 References: <48B50A7A.8040002@ericsson.com> <20080828.090805.254804201.mbj@tail-f.com> In-Reply-To: <20080828.090805.254804201.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808281426.45930.david.partain@ericsson.com> X-OriginalArrivalTime: 28 Aug 2008 12:26:46.0073 (UTC) FILETIME=[561AEA90:01C90909] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] with-defaults draft submitted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I certainly support the NETCONF working group taking on this work and starting from draft-bierman-netconf-with-defaults-00.txt Cheers, David _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 28 05:59:14 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 396893A6C97; Thu, 28 Aug 2008 05:59:14 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBC4E28C278 for ; Thu, 28 Aug 2008 05:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoFa3rn1o8ap for ; Thu, 28 Aug 2008 05:59:12 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 92E403A6C96 for ; Thu, 28 Aug 2008 05:59:12 -0700 (PDT) X-Trace: 75462453/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.50.135 X-SBRS: None X-RemoteIP: 213.116.50.135 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYEAPM9tkjVdDKH/2dsb2JhbACDRziICa5LA4Fm X-IronPort-AV: E=Sophos;i="4.32,286,1217804400"; d="scan'208";a="75462453" X-IP-Direction: IN Received: from 1cust135.tnt101.lnd4.gbr.da.uu.net (HELO allison) ([213.116.50.135]) by smtp.pipex.tiscali.co.uk with SMTP; 28 Aug 2008 13:59:08 +0100 Message-ID: <046b01c90904$89d003c0$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" , "Phil Shafer" References: <200808202134.m7KLYLOZ003375@idle.juniper.net> <48AF3DD0.7010800@netconfcentral.com> Date: Thu, 28 Aug 2008 13:50:52 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: NETCONF Subject: Re: [Netconf] continue-on-error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org ----- Original Message ----- From: "Andy Bierman" To: "Phil Shafer" Cc: "NETCONF" Sent: Saturday, August 23, 2008 12:29 AM Subject: Re: [Netconf] continue-on-error > Phil Shafer wrote: > > Andy Bierman writes: > >> But first, does anybody implement continue-on-error, > >> and if so, what does it really mean in your agent? > > > > "continue-on-error" means "do your best to keep going". > > "your best" can't be defined easily, since you're > > facing input that contains errors. > > pretty vague. > I used to think it meant there are no errors > detected in syntax or constraints, but if > an error occurred trying to apply the > (e.g., malloc failed), then try to continue. > > Clearly this is the intent if test-option 'test-then-set' is true. > (It actually requires more -- a must succeed too.) > > But for my internal operation, using the > same infrastructure as , I want to > skip over syntax errors in one subtree if another subtree > is good. > > You are suggesting that even for , skipping > over invalid well-formed XML is OK for 'continue-on-error'. > Seems fine to me, since the spec doesn't really say. > 'continue-on-error' is what (almost?) every HTML browser does. Look at the source for web sites and many if not most is invalid, at least in the sense of using mismatched start and end tags, eg for

  • etc so there seems a general implementation rule that if a is missing, supply it. Easier to do for syntax errors than for misspelt QNaems. The better systems I am used to have a classification of errors - eg minor, severe, catastrophic - with different actions specifiable for each. The systems I dislike most are the ones that continue on catastrophic errors thus generating hundreds or thousands of error messages for one typo (something I see with SMI checkers:-( Tom Petch > > > Thanks, > > Phil > > > > Andy > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 28 05:59:14 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 396893A6C97; Thu, 28 Aug 2008 05:59:14 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBC4E28C278 for ; Thu, 28 Aug 2008 05:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoFa3rn1o8ap for ; Thu, 28 Aug 2008 05:59:12 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 92E403A6C96 for ; Thu, 28 Aug 2008 05:59:12 -0700 (PDT) X-Trace: 75462453/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.50.135 X-SBRS: None X-RemoteIP: 213.116.50.135 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYEAPM9tkjVdDKH/2dsb2JhbACDRziICa5LA4Fm X-IronPort-AV: E=Sophos;i="4.32,286,1217804400"; d="scan'208";a="75462453" X-IP-Direction: IN Received: from 1cust135.tnt101.lnd4.gbr.da.uu.net (HELO allison) ([213.116.50.135]) by smtp.pipex.tiscali.co.uk with SMTP; 28 Aug 2008 13:59:08 +0100 Message-ID: <046b01c90904$89d003c0$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" , "Phil Shafer" References: <200808202134.m7KLYLOZ003375@idle.juniper.net> <48AF3DD0.7010800@netconfcentral.com> Date: Thu, 28 Aug 2008 13:50:52 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: NETCONF Subject: Re: [Netconf] continue-on-error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org ----- Original Message ----- From: "Andy Bierman" To: "Phil Shafer" Cc: "NETCONF" Sent: Saturday, August 23, 2008 12:29 AM Subject: Re: [Netconf] continue-on-error > Phil Shafer wrote: > > Andy Bierman writes: > >> But first, does anybody implement continue-on-error, > >> and if so, what does it really mean in your agent? > > > > "continue-on-error" means "do your best to keep going". > > "your best" can't be defined easily, since you're > > facing input that contains errors. > > pretty vague. > I used to think it meant there are no errors > detected in syntax or constraints, but if > an error occurred trying to apply the > (e.g., malloc failed), then try to continue. > > Clearly this is the intent if test-option 'test-then-set' is true. > (It actually requires more -- a must succeed too.) > > But for my internal operation, using the > same infrastructure as , I want to > skip over syntax errors in one subtree if another subtree > is good. > > You are suggesting that even for , skipping > over invalid well-formed XML is OK for 'continue-on-error'. > Seems fine to me, since the spec doesn't really say. > 'continue-on-error' is what (almost?) every HTML browser does. Look at the source for web sites and many if not most is invalid, at least in the sense of using mismatched start and end tags, eg for

  • etc so there seems a general implementation rule that if a is missing, supply it. Easier to do for syntax errors than for misspelt QNaems. The better systems I am used to have a classification of errors - eg minor, severe, catastrophic - with different actions specifiable for each. The systems I dislike most are the ones that continue on catastrophic errors thus generating hundreds or thousands of error messages for one typo (something I see with SMI checkers:-( Tom Petch > > > Thanks, > > Phil > > > > Andy > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 28 07:39:25 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DBC228C1EE; Thu, 28 Aug 2008 07:39:25 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBF663A6AEC for ; Thu, 28 Aug 2008 07:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[AWL=-0.107, 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 E0NdRdp91-51 for ; Thu, 28 Aug 2008 07:39:23 -0700 (PDT) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id DC86C3A6CBB for ; Thu, 28 Aug 2008 07:39:22 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA08.westchester.pa.mail.comcast.net with comcast id 7owA1a0080bG4ec58qfNCY; Thu, 28 Aug 2008 14:39:22 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA03.westchester.pa.mail.comcast.net with comcast id 7qfM1a00M4HwxpC3PqfNNy; Thu, 28 Aug 2008 14:39:22 +0000 X-Authority-Analysis: v=1.0 c=1 a=YiSIE_LXjtaUMvqV5NIA:9 a=gtjxtZ87vaKsYzTDz1IA:7 a=03kviixG0Jb5RHWO4uZK2aRDy9kA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Thu, 28 Aug 2008 10:39:21 -0400 Message-ID: <036301c9091b$dc473170$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AckJG9vsGP5o5Fy3Rf+lv5Hko35qhw== Subject: [Netconf] netconf-tls X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, The syslog WG is finalizing their document on syslog-tls. The IESG review raised a number of DISCUSSES for important security issues. draft-hodges-server-ident-check-00 is an attempt to standardize how applications check server identities using TLS. I strongly recommend the editors of netconf-tls pay close attention to the work being done for syslog-tls and the hodges draft, to ensure consistency and compatibility and to ease the approval path. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 28 07:39:25 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DBC228C1EE; Thu, 28 Aug 2008 07:39:25 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBF663A6AEC for ; Thu, 28 Aug 2008 07:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[AWL=-0.107, 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 E0NdRdp91-51 for ; Thu, 28 Aug 2008 07:39:23 -0700 (PDT) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id DC86C3A6CBB for ; Thu, 28 Aug 2008 07:39:22 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA08.westchester.pa.mail.comcast.net with comcast id 7owA1a0080bG4ec58qfNCY; Thu, 28 Aug 2008 14:39:22 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA03.westchester.pa.mail.comcast.net with comcast id 7qfM1a00M4HwxpC3PqfNNy; Thu, 28 Aug 2008 14:39:22 +0000 X-Authority-Analysis: v=1.0 c=1 a=YiSIE_LXjtaUMvqV5NIA:9 a=gtjxtZ87vaKsYzTDz1IA:7 a=03kviixG0Jb5RHWO4uZK2aRDy9kA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Thu, 28 Aug 2008 10:39:21 -0400 Message-ID: <036301c9091b$dc473170$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AckJG9vsGP5o5Fy3Rf+lv5Hko35qhw== Subject: [Netconf] netconf-tls X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, The syslog WG is finalizing their document on syslog-tls. The IESG review raised a number of DISCUSSES for important security issues. draft-hodges-server-ident-check-00 is an attempt to standardize how applications check server identities using TLS. I strongly recommend the editors of netconf-tls pay close attention to the work being done for syslog-tls and the hodges draft, to ensure consistency and compatibility and to ease the approval path. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 28 10:01:15 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ED9F3A67AF; Thu, 28 Aug 2008 10:01:15 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A31A3A67AF for ; Thu, 28 Aug 2008 10:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.805 X-Spam-Level: X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxeCbA-Xif81 for ; Thu, 28 Aug 2008 10:01:13 -0700 (PDT) Received: from dmzms99802.na.baesystems.com (dmzms99802.na.baesystems.com [149.32.232.66]) by core3.amsl.com (Postfix) with ESMTP id 6D5453A67AE for ; Thu, 28 Aug 2008 10:01:09 -0700 (PDT) Message-Id: <738m08$6sj4q@dmzms99802.na.baesystems.com> X-SENDER-IP: 10.37.193.66 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.32,287,1217808000"; d="scan'208,217";a="7228570" Received: from rfc1918.na.baesystems.com (HELO vahnms99902.na.baesystems.com) ([10.37.193.66]) by dmzms99802.na.baesystems.com with ESMTP/TLS/RC4-SHA; 28 Aug 2008 17:00:51 +0000 X-SENDER-IP: 10.40.96.103 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.32,287,1217808000"; d="scan'208,217";a="1985449" X-MimeOLE: Produced By Microsoft Exchange V6.0.6619.12 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Aug 2008 13:00:50 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Netconf/netmod implementations Thread-Index: AckJL5+BQF9oodmHT2OY3kjtBtM8HA== From: "Frye, Robert J \(US SSA\)" To: X-OriginalArrivalTime: 28 Aug 2008 17:00:50.0585 (UTC) FILETIME=[9FCC5090:01C9092F] Subject: [Netconf] Netconf/netmod implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1065979060==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1065979060== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9092F.9FAEFC07" This is a multi-part message in MIME format. ------_=_NextPart_001_01C9092F.9FAEFC07 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I have been lurking on the list for some time. I am interested as a potential purchaser (either for my company and/or as part of a solution for our customers) in what the state is of implementations and interoperability tests of NETCONF & NETMOD. Who has implemented these in management systems? Who has implemented them in managed network devices? What is the status of or plan for shipping products? What testing has been done to ensure compatibility of implementations? =20 Thank you, Rob Frye Sr. Architect, Information Integration & Assurance BAE Systems/Network Systems C&TN 11487 Sunset Hills Rd #306A Reston, VA 20190 o: 703-668-4418, c:703-336-3371, f: 703-668-4360 =20 ------_=_NextPart_001_01C9092F.9FAEFC07 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

    I have been lurking on the list for some time. =  I am interested as a potential purchaser (either for my company and/or as = part of a solution for our customers) in what the state is of implementations and interoperability tests of NETCONF & NETMOD.  Who has = implemented these in management systems?  Who has implemented them in managed network devices?  What is the status of or plan for shipping = products?  What testing has been done to ensure compatibility of = implementations?

     

    Thank you,

    Rob = Frye

    Sr. Architect, Information Integration & = Assurance

    BAE Systems/Network Systems = C&TN

    11487 = Sunset Hills Rd #306A

    Reston, VA 20190

    o: 703-668-4418, c:703-336-3371, f: = 703-668-4360

     

    ------_=_NextPart_001_01C9092F.9FAEFC07-- --===============1065979060== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1065979060==-- From netconf-bounces@ietf.org Thu Aug 28 10:01:15 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ED9F3A67AF; Thu, 28 Aug 2008 10:01:15 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A31A3A67AF for ; Thu, 28 Aug 2008 10:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.805 X-Spam-Level: X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxeCbA-Xif81 for ; Thu, 28 Aug 2008 10:01:13 -0700 (PDT) Received: from dmzms99802.na.baesystems.com (dmzms99802.na.baesystems.com [149.32.232.66]) by core3.amsl.com (Postfix) with ESMTP id 6D5453A67AE for ; Thu, 28 Aug 2008 10:01:09 -0700 (PDT) Message-Id: <738m08$6sj4q@dmzms99802.na.baesystems.com> X-SENDER-IP: 10.37.193.66 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.32,287,1217808000"; d="scan'208,217";a="7228570" Received: from rfc1918.na.baesystems.com (HELO vahnms99902.na.baesystems.com) ([10.37.193.66]) by dmzms99802.na.baesystems.com with ESMTP/TLS/RC4-SHA; 28 Aug 2008 17:00:51 +0000 X-SENDER-IP: 10.40.96.103 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.32,287,1217808000"; d="scan'208,217";a="1985449" X-MimeOLE: Produced By Microsoft Exchange V6.0.6619.12 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Aug 2008 13:00:50 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Netconf/netmod implementations Thread-Index: AckJL5+BQF9oodmHT2OY3kjtBtM8HA== From: "Frye, Robert J \(US SSA\)" To: X-OriginalArrivalTime: 28 Aug 2008 17:00:50.0585 (UTC) FILETIME=[9FCC5090:01C9092F] Subject: [Netconf] Netconf/netmod implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1065979060==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1065979060== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9092F.9FAEFC07" This is a multi-part message in MIME format. ------_=_NextPart_001_01C9092F.9FAEFC07 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I have been lurking on the list for some time. I am interested as a potential purchaser (either for my company and/or as part of a solution for our customers) in what the state is of implementations and interoperability tests of NETCONF & NETMOD. Who has implemented these in management systems? Who has implemented them in managed network devices? What is the status of or plan for shipping products? What testing has been done to ensure compatibility of implementations? =20 Thank you, Rob Frye Sr. Architect, Information Integration & Assurance BAE Systems/Network Systems C&TN 11487 Sunset Hills Rd #306A Reston, VA 20190 o: 703-668-4418, c:703-336-3371, f: 703-668-4360 =20 ------_=_NextPart_001_01C9092F.9FAEFC07 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

    I have been lurking on the list for some time. =  I am interested as a potential purchaser (either for my company and/or as = part of a solution for our customers) in what the state is of implementations and interoperability tests of NETCONF & NETMOD.  Who has = implemented these in management systems?  Who has implemented them in managed network devices?  What is the status of or plan for shipping = products?  What testing has been done to ensure compatibility of = implementations?

     

    Thank you,

    Rob = Frye

    Sr. Architect, Information Integration & = Assurance

    BAE Systems/Network Systems = C&TN

    11487 = Sunset Hills Rd #306A

    Reston, VA 20190

    o: 703-668-4418, c:703-336-3371, f: = 703-668-4360

     

    ------_=_NextPart_001_01C9092F.9FAEFC07-- --===============1065979060== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1065979060==-- From netconf-bounces@ietf.org Thu Aug 28 11:48:10 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D50C3A680F; Thu, 28 Aug 2008 11:48:10 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803033A67DB for ; Thu, 28 Aug 2008 11:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pp8JhVdvj0XN for ; Thu, 28 Aug 2008 11:48:07 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 713E83A67B7 for ; Thu, 28 Aug 2008 11:48:07 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m7SJmFYu643146; Thu, 28 Aug 2008 20:48:15 +0100 Received: from 88.175.65.115 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Thu, 28 Aug 2008 20:42:29 +0200 (CEST) Message-ID: <49512.88.175.65.115.1219948949.squirrel@www.isima.fr> In-Reply-To: <036301c9091b$dc473170$0600a8c0@china.huawei.com> References: <036301c9091b$dc473170$0600a8c0@china.huawei.com> Date: Thu, 28 Aug 2008 20:42:29 +0200 (CEST) From: badra@isima.fr To: =?utf-8?Q?David=C2_Harrington=C2?= User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Thu, 28 Aug 2008 20:48:17 +0100 (WEST) Cc: netconf@ietf.org Subject: Re: [Netconf] =?utf-8?q?=C2=A0netconf-tls?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear David, I read the draft (expired since 2 weeks), which extracts the "server identity check" from RFC4513, and I think it is equivalent to Section 5 of RFC4642 (used by "Netconf over TLS"). However, it is a good idea to standardize how applications check server identities using TLS, and I will update the document with regards to IESG comments on syslog-tls regarding the identity check. Best regards Badra > The syslog WG is finalizing their document on syslog-tls. The IESG > review raised a number of DISCUSSES for important security issues. > > draft-hodges-server-ident-check-00 is an attempt to standardize how > applications check server identities using TLS. I strongly recommend > the editors of netconf-tls pay close attention to the work being done > for syslog-tls and the hodges draft, to ensure consistency and > compatibility and to ease the approval path. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 28 11:48:10 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D50C3A680F; Thu, 28 Aug 2008 11:48:10 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803033A67DB for ; Thu, 28 Aug 2008 11:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pp8JhVdvj0XN for ; Thu, 28 Aug 2008 11:48:07 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 713E83A67B7 for ; Thu, 28 Aug 2008 11:48:07 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m7SJmFYu643146; Thu, 28 Aug 2008 20:48:15 +0100 Received: from 88.175.65.115 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Thu, 28 Aug 2008 20:42:29 +0200 (CEST) Message-ID: <49512.88.175.65.115.1219948949.squirrel@www.isima.fr> In-Reply-To: <036301c9091b$dc473170$0600a8c0@china.huawei.com> References: <036301c9091b$dc473170$0600a8c0@china.huawei.com> Date: Thu, 28 Aug 2008 20:42:29 +0200 (CEST) From: badra@isima.fr To: =?utf-8?Q?David=C2_Harrington=C2?= User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Thu, 28 Aug 2008 20:48:17 +0100 (WEST) Cc: netconf@ietf.org Subject: Re: [Netconf] =?utf-8?q?=C2=A0netconf-tls?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear David, I read the draft (expired since 2 weeks), which extracts the "server identity check" from RFC4513, and I think it is equivalent to Section 5 of RFC4642 (used by "Netconf over TLS"). However, it is a good idea to standardize how applications check server identities using TLS, and I will update the document with regards to IESG comments on syslog-tls regarding the identity check. Best regards Badra > The syslog WG is finalizing their document on syslog-tls. The IESG > review raised a number of DISCUSSES for important security issues. > > draft-hodges-server-ident-check-00 is an attempt to standardize how > applications check server identities using TLS. I strongly recommend > the editors of netconf-tls pay close attention to the work being done > for syslog-tls and the hodges draft, to ensure consistency and > compatibility and to ease the approval path. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Aug 28 13:23:39 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCBC53A6A21; Thu, 28 Aug 2008 13:23:39 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C90F33A69B6 for ; Thu, 28 Aug 2008 13:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 bO1Ky5-8CkUC for ; Thu, 28 Aug 2008 13:23:37 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by core3.amsl.com (Postfix) with SMTP id 8B93F3A6AAD for ; Thu, 28 Aug 2008 13:23:37 -0700 (PDT) Received: (qmail 37882 invoked from network); 28 Aug 2008 20:23:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 28 Aug 2008 20:23:30 -0000 X-YMail-OSG: zE9KDnkVM1lcsgjLUcCbFvWgdixg1CKUpw73BYgPVrYEYyxds_tMO5tQqJVnVRIIKkoj8J0ImxVRkpW32yVpqwzJYvtVXyqVmLqVTo0WnynOj9nzj.mkcTnNCzh3dPs- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B70940.6040200@netconfcentral.com> Date: Thu, 28 Aug 2008 13:23:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808271414.m7REEO1d098491@idle.juniper.net> In-Reply-To: <200808271414.m7REEO1d098491@idle.juniper.net> Cc: netconf mailing list Subject: Re: [Netconf] with-defaults draft submitted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Balazs Lengyel writes: >... >> The NETCONF >> agent MUST also indicate it's default behavior, whether it sends >> default data in the absence of any specific request from the NETCONF >> manager. > > Do we need this feature? Can it simply default to "off"? Isn't > it a pain to check the state before knowing you can turn it off? > Some people have commented that the default MUST be 'on' instead of 'off'. If the application knows which is the default, that is good enough. Old managers do not know about the new with-defaults capability no matter what the default. Old managers should keep getting whatever response they used to get, before YANG came along and starting making all these CLRs. So there cannot be a default because RFC 4741 never mentions filtering out agent-supplied values at all. This either means that the agent MUST NOT filter out any values or it means the agent can do whatever it wants. Assuming we agree on the latter, then the agent should be free to keep the same default behavior it already supports. >> The identifier MAY have a second parameter indicating how it treats >> explicitly set default data. If the explicit-default parameter is >> set to "unrecognized" the agent MUST treat explicitly set default >> data as normal default data. If the parameter is set to rFrom netconf-bounces@ietf.org Thu Aug 28 13:23:39 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCBC53A6A21; Thu, 28 Aug 2008 13:23:39 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C90F33A69B6 for ; Thu, 28 Aug 2008 13:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 bO1Ky5-8CkUC for ; Thu, 28 Aug 2008 13:23:37 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by core3.amsl.com (Postfix) with SMTP id 8B93F3A6AAD for ; Thu, 28 Aug 2008 13:23:37 -0700 (PDT) Received: (qmail 37882 invoked from network); 28 Aug 2008 20:23:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.138.23 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 28 Aug 2008 20:23:30 -0000 X-YMail-OSG: zE9KDnkVM1lcsgjLUcCbFvWgdixg1CKUpw73BYgPVrYEYyxds_tMO5tQqJVnVRIIKkoj8J0ImxVRkpW32yVpqwzJYvtVXyqVmLqVTo0WnynOj9nzj.mkcTnNCzh3dPs- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48B70940.6040200@netconfcentral.com> Date: Thu, 28 Aug 2008 13:23:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200808271414.m7REEO1d098491@idle.juniper.net> In-Reply-To: <200808271414.m7REEO1d098491@idle.juniper.net> Cc: netconf mailing list Subject: Re: [Netconf] with-defaults draft submitted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Balazs Lengyel writes: >... >> The NETCONF >> agent MUST also indicate it's default behavior, whether it sends >> default data in the absence of any specific request from the NETCONF >> manager. > > Do we need this feature? Can it simply default to "off"? Isn't > it a pain to check the state before knowing you can turn it off? > Some people have commented that the default MUST be 'on' instead of 'off'. If the application knows which is the default, that is good enough. Old managers do not know about the new with-defaults capability no matter what the default. Old managers should keep getting whatever response they used to get, before YANG came along and starting making all these CLRs. So there cannot be a default because RFC 4741 never mentions filtering out agent-supplied values at all. This either means that the agent MUST NOT filter out any values or it means the agent can do whatever it wants. Assuming we agree on the latter, then the agent should be free to keep the same default behavior it already supports. >> The identifier MAY have a second parameter indicating how it treats >> explicitly set default data. If the explicit-default parameter is >> set to "unrecognized" the agent MUST treat explicitly set default >> data as normal default data. If the parameter is seecognized >> this means that such data is not treated as default data. All other >> values for the parameter or a missing parameter is handled as the >> value unrecognized. >> >> urn:ietf:params:netconf:capability:with-defaults?default=false& >> explicit-default=recognized > > Is there a more suitable term than "recognized"? Even "true" > seems more clear. > >> A new 'with-defaults' XML attribute is used to control the generation >> of default data. If the 'with-defaults' attribute is present in the >> element, of the affected operations, the agent will use it's >> value to control whether default data is returned in the NETCONF rpc >> reply messages. > > I strongly dislike putting this as an attribute on : > I do not mind making them leafs instead. It could be argued that the attrributes in the element are intended as a vendor sandbox, but that doesn't mean standards should also use it. > 1) It's a horrible precedent. Imagine every capability defining > an attribute instead of modifying the proper operations. > will become a dumping ground. > > 2) with-defaults isn't a generic attribute, but applies to > a specific set of operations. Better to have it ties directly > to those operations via a new element within their > arguments (in YANG-speak). The list of affected operations is > short enough that this is a simple solution: > >> Affected operations: >> o >> o >> o > > Putting in on the is like making it an argument to every RPC > but ignoring it for all but these three. > > 3) In YANG, this capability would be an augmentation of the input > arguments to those three operations. There's no mechanism in YANG > to address adding an attribute to . > >> Index clause components are not subject to default suppression. > > "index clause"? Is that snmp-speak? > >> If >> an element within the configuration database is considered to be part >> of a key, and represents one of the naming components for a >> conceptual data structure which allows multiple named instances of an >> ancestor node, then this element is never suppressed, regardless of >> the value of the 'with-defaults' attribute. > > Keys don't have default values, so this isn't really an issue. > >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> >> >> >> > > Should be: > > xmlns:wdef="urn:whatever:netconf:with-defaults" > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > false > > > > > > >> 7.1. Augmenting the base RPCs >> >> Instead of using an attribute on the RPC element we could "augment" >> the relevant NETCONF operations with an extra XML element with a >> similar meaning. > > Coooool....... > >> Pro: parameters on RPC are for vendor extensions. We should not put >> standard stuff there. > > See other Pros above. > >> Contra: Some people might consider this a violation of [RFC4741] as >> the XSD does not allow adding new elements. As there is no NETCONF >> YAM (at least not yet), what do we actually augment? Also there are >> multiple ways of defining RFC4741 in YANG. The description will be >> perfectly clear, but it can never be fed into YANG tools. > > If you see this as a violation, you are condemning all future changes > to base operations to the same fate. I'd say declare this lack of > flexibility in 4741's XSD a bug and fix it there. > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netct to recognized >> this means that such data is not treated as default data. All other >> values for the parameter or a missing parameter is handled as the >> value unrecognized. >> >> urn:ietf:params:netconf:capability:with-defaults?default=false& >> explicit-default=recognized > > Is there a more suitable term than "recognized"? Even "true" > seems more clear. > >> A new 'with-defaults' XML attribute is used to control the generation >> of default data. If the 'with-defaults' attribute is present in the >> element, of the affected operations, the agent will use it's >> value to control whether default data is returned in the NETCONF rpc >> reply messages. > > I strongly dislike putting this as an attribute on : > I do not mind making them leafs instead. It could be argued that the attrributes in the element are intended as a vendor sandbox, but that doesn't mean standards should also use it. > 1) It's a horrible precedent. Imagine every capability defining > an attribute instead of modifying the proper operations. > will become a dumping ground. > > 2) with-defaults isn't a generic attribute, but applies to > a specific set of operations. Better to have it ties directly > to those operations via a new element within their > arguments (in YANG-speak). The list of affected operations is > short enough that this is a simple solution: > >> Affected operations: >> o >> o >> o > > Putting in on the is like making it an argument to every RPC > but ignoring it for all but these three. > > 3) In YANG, this capability would be an augmentation of the input > arguments to those three operations. There's no mechanism in YANG > to address adding an attribute to . > >> Index clause components are not subject to default suppression. > > "index clause"? Is that snmp-speak? > >> If >> an element within the configuration database is considered to be part >> of a key, and represents one of the naming components for a >> conceptual data structure which allows multiple named instances of an >> ancestor node, then this element is never suppressed, regardless of >> the value of the 'with-defaults' attribute. > > Keys don't have default values, so this isn't really an issue. > >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> >> >> >> > > Should be: > > xmlns:wdef="urn:whatever:netconf:with-defaults" > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > false > > > > > > >> 7.1. Augmenting the base RPCs >> >> Instead of using an attribute on the RPC element we could "augment" >> the relevant NETCONF operations with an extra XML element with a >> similar meaning. > > Coooool....... > >> Pro: parameters on RPC are for vendor extensions. We should not put >> standard stuff there. > > See other Pros above. > >> Contra: Some people might consider this a violation of [RFC4741] as >> the XSD does not allow adding new elements. As there is no NETCONF >> YAM (at least not yet), what do we actually augment? Also there are >> multiple ways of defining RFC4741 in YANG. The description will be >> perfectly clear, but it can never be fed into YANG tools. > > If you see this as a violation, you are condemning all future changes > to base operations to the same fate. I'd say declare this lack of > flexibility in 4741's XSD a bug and fix it there. > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfonf > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf o/netconf > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf