From netconf-bounces@ietf.org Sat Nov 1 07:28: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 7E6F53A6880; Sat, 1 Nov 2008 07:28: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 0A1273A6880 for ; Sat, 1 Nov 2008 07:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3-isAwDtDCh for ; Sat, 1 Nov 2008 07:28:44 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id C70E23A685B for ; Sat, 1 Nov 2008 07:28:43 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1KwHSB-0000Ks-4J for netconf@ietf.org; Sat, 01 Nov 2008 15:27:51 +0100 Message-ID: From: "Bert Wijnen \(IETF\)" To: "netconf mailing list" References: <490B29FB.4080200@ericsson.com> In-Reply-To: <490B29FB.4080200@ericsson.com> Date: Sat, 1 Nov 2008 15:24:09 +0100 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: Re: [Netconf] [Fwd: New Version Notification fordraft-ietf-netconf-partial-lock-04] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1644491524==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1644491524== Content-Type: multipart/alternative; boundary="----=_NextPart_000_06B8_01C93C35.E2BD4D80" This is a multi-part message in MIME format. ------=_NextPart_000_06B8_01C93C35.E2BD4D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ALL WG members/particiapnts. Pls give this document a final check. If att all possible, pls do so before Nov 7th, so we (WG chairs) can submit it to our AD before the upcoming IETF. Bert and Mehmet ----- Original Message -----=20 From: Balazs Lengyel=20 To: netconf mailing list=20 Sent: Friday, October 31, 2008 4:53 PM Subject: [Netconf] [Fwd: New Version Notification = fordraft-ietf-netconf-partial-lock-04] Hello, I have submitted a new version of the draft. I believe we addressed = all comments of the WG last=20 call in this version. IMHO the draft is ready for IESG review, BUT please check that your comments are included! Thanks for all the comments. Balazs -------- Original Message -------- Subject: New Version Notification for = draft-ietf-netconf-partial-lock-04 Date: Fri, 31 Oct 2008 08:48:39 -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-04.txt has been = successfuly submiFrom netconf-bounces@ietf.org Sat Nov 1 07:28: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 7E6F53A6880; Sat, 1 Nov 2008 07:28: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 0A1273A6880 for ; Sat, 1 Nov 2008 07:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3-isAwDtDCh for ; Sat, 1 Nov 2008 07:28:44 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id C70E23A685B for ; Sat, 1 Nov 2008 07:28:43 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1KwHSB-0000Ks-4J for netconf@ietf.org; Sat, 01 Nov 2008 15:27:51 +0100 Message-ID: From: "Bert Wijnen \(IETF\)" To: "netconf mailing list" References: <490B29FB.4080200@ericsson.com> In-Reply-To: <490B29FB.4080200@ericsson.com> Date: Sat, 1 Nov 2008 15:24:09 +0100 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: Re: [Netconf] [Fwd: New Version Notification fordraft-ietf-netconf-partial-lock-04] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1644491524==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1644491524== Content-Type: multipart/alternative; boundary="----=_NextPart_000_06B8_01C93C35.E2BD4D80" This is a multi-part message in MIME format. ------=_NextPart_000_06B8_01C93C35.E2BD4D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ALL WG members/particiapnts. Pls give this document a final check. If att all possible, pls do so before Nov 7th, so we (WG chairs) can submit it to our AD before the upcoming IETF. Bert and Mehmet ----- Original Message -----=20 From: Balazs Lengyel=20 To: netconf mailing list=20 Sent: Friday, October 31, 2008 4:53 PM Subject: [Netconf] [Fwd: New Version Notification = fordraft-ietf-netconf-partial-lock-04] Hello, I have submitted a new version of the draft. I believe we addressed = all comments of the WG last=20 call in this version. IMHO the draft is ready for IESG review, BUT please check that your comments are included! Thanks for all the comments. Balazs -------- Original Message -------- Subject: New Version Notification for = draft-ietf-netconf-partial-lock-04 Date: Fri, 31 Oct 2008 08:48:39 -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-04.txt has been = successfulytted by=20 Balazs Lengyel and posted to the IETF repository. Filename: draft-ietf-netconf-partial-lock Revision: 04 Title: Partial Lock RPC for NETCONF Creation_date: 2008-10-29 WG ID: netconf Number_of_pages: 24 Abstract: The NETCONF protocol defines the lock and unlock RPCs, used to lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. The IETF Secretariat. --=20 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 ------=_NextPart_000_06B8_01C93C35.E2BD4D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
ALL WG members/particiapnts.
Pls give this document a final check. If att all = possible,=20 pls
do so before Nov 7th, so we (WG chairs) can submit = it to our=20 AD
before the upcoming IETF.
 
Bert and Mehmet
----- Original Message -----
From:=20 Balazs Lengyel
Sent: Friday, October 31, 2008 = 4:53=20 PM
Subject: [Netconf] [Fwd: New = Version=20 Notification fordraft-ietf-netconf-partial-lock-04]

Hello,
I have submitted a new version of the draft. = I=20 believe we addressed all comments of the WG last
call in this = version.=20 IMHO the draft is ready for IESG review, BUT

please check that = your=20 comments are included!

Thanks for all the=20 comments.

Balazs

-------- Original Message = --------
Subject:=20 New Version Notification for = draft-ietf-netconf-partial-lock-04
Date: Fri,=20 31 Oct 2008 08:48:39 -0700 (PDT)
From: IETF I-D Submission Tool = <idsubmission@ietf.org>
To= : balazs.lengyel@ericsson.com
CC:=20 mbj@tail-f.com


A new = version of=20 I-D, draft-ietf-netconf-partial-lock-04.txt has been successfuly = submitted by=20
Balazs Lengyel and posted to the IETF repository.

Filename: = draft-ietf-netconf-partial-lock
Revision: 04
Title: Partial Lock = RPC for=20 NETCONF
Creation_date: 2008-10-29
WG ID: = netconf
Number_of_pages:=20 24

Abstract:
The NETCONF protocol defines the lock and = unlock RPCs,=20 used to lock
entire configuration datastores.  In some = situations, a=20 way to lock
only parts of a configuration datastore is = required.  This=20 document
defines a capability-based extension to the NETCONF = protocol=20 for
locking portions of a configuration = datastore.
ALL WG members/particiapnts.
Pls give this document a final check. If att all = possible,=20 pls
do so before Nov 7th, so we (WG chairs) can submit = it to our=20 AD
before the upcoming IETF.
 
Bert and Mehmet
----- Original Message -----
From:=20 Balazs Lengyel
Sent: Friday, October 31, 2008 = 4:53=20 PM
Subject: [Netconf] [Fwd: New = Version=20 Notification fordraft-ietf-netconf-partial-lock-04]

Hello,
I have submitted a new version of the draft. = I=20 believe we addressed all comments of the WG last
call in this = version.=20 IMHO the draft is ready for IESG review, BUT

please check that = your=20 comments are included!

Thanks for all the=20 comments.

Balazs

-------- Original Message = --------
Subject:=20 New Version Notification for = draft-ietf-netconf-partial-lock-04
Date: Fri,=20 31 Oct 2008 08:48:39 -0700 (PDT)
From: IETF I-D Submission Tool = <idsubmission@ietf.org>
To= : balazs.lengyel@ericsson.com
CC:=20 mbj@tail-f.com


A new = version of=20 I-D, draft-ietf-netconf-partial-lock-04.txt has been successfuly = submitted by=20
Balazs Lengyel and posted to the IETF repository.

Filename: = draft-ietf-netconf-partial-lock
Revision: 04
Title: Partial Lock = RPC for=20 NETCONF
Creation_date: 2008-10-29
WG ID: = netconf
Number_of_pages:=20 24

Abstract:
The NETCONF protocol defines the lock and = unlock RPCs,=20 used to lock
entire configuration datastores.  In some = situations, a=20 way to lock
only parts of a configuration datastore is = required.  This=20 document
defines a capability-based extension to the NETCONF = protocol=20 for
locking portions of a configuration = datasto>


The IETF=20 Secretariat.



--
Balazs=20 = Lengyel           =            =20 Ericsson Hungary Ltd.
TSP System Manager
ECN: 831=20 = 7320           &nb= sp;           =20 Fax: +36 1 4377792
Tel: +36-1-437-7320     = email: Balazs.Lengyel@ericsson.com
_______________________________________________
Netconf=20 mailing list
Netconf@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netconf

------=_NextPart_000_06B8_01C93C35.E2BD4D80-- --===============1644491524== 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 --===============1644491524==-- re.



The IETF=20 Secretariat.



--
Balazs=20 = Lengyel           =            =20 Ericsson Hungary Ltd.
TSP System Manager
ECN: 831=20 = 7320           &nb= sp;           =20 Fax: +36 1 4377792
Tel: +36-1-437-7320     = email: Balazs.Lengyel@ericsson.com
_______________________________________________
Netconf=20 mailing list
Netconf@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netconf

------=_NextPart_000_06B8_01C93C35.E2BD4D80-- --===============1644491524== 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 --===============1644491524==-- From netconf-bounces@ietf.org Sun Nov 2 03:51: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 882C33A6846; Sun, 2 Nov 2008 03:51:51 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3EF63A67D9; Sun, 2 Nov 2008 03:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 JlmDk5UbHdGS; Sun, 2 Nov 2008 03:51:50 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 4FAD13A67D0; Sun, 2 Nov 2008 03:51:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,529,1220241600"; d="scan'208";a="126989161" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Nov 2008 06:51:45 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Nov 2008 06:51:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 2 Nov 2008 12:51:43 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5381 on Experience of Implementing NETCONF over SOAP Thread-Index: Ack7p6+JbUB3ATGSSe6+4/X6OyTvZwBOacnA From: "Romascanu, Dan (Dan)" To: , Subject: [Netconf] FW: RFC 5381 on Experience of Implementing NETCONF over SOAP X-BeenThere: netconf@ietf.org X-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 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org Sent: Saturday, November 01, 2008 12:25 AM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: rfc-editor@rfc-editor.org Subject: RFC 5381 on Experience of Implementing NETCONF over SOAP A new Request for Comments is now available in online RFC libraries. RFC 5381 Title: Experience of Implementing NETCONF over SOAP Author: T. Iijima, Y. Atarashi, H. Kimura, M. Kitani, H. Okita Status: Informational Date: October 2008 Mailbox: tomoyuki.iijima@alaxala.com, atarashi@alaxala.net, h-kimura@alaxala.net, makoto.kitani@alaxala.com, hideki.okita.pf@hitachi.com Pages: 22 Characters: 47724 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-iijima-netconf-soap-implementation-10.txt URL: http://www.rfc-editor.org/rfc/rfc5381.txt This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF (Network Configuration Protocol) client and server. It describes From netconf-bounces@ietf.org Sun Nov 2 03:51: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 882C33A6846; Sun, 2 Nov 2008 03:51:51 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3EF63A67D9; Sun, 2 Nov 2008 03:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 JlmDk5UbHdGS; Sun, 2 Nov 2008 03:51:50 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 4FAD13A67D0; Sun, 2 Nov 2008 03:51:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,529,1220241600"; d="scan'208";a="126989161" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Nov 2008 06:51:45 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Nov 2008 06:51:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 2 Nov 2008 12:51:43 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5381 on Experience of Implementing NETCONF over SOAP Thread-Index: Ack7p6+JbUB3ATGSSe6+4/X6OyTvZwBOacnA From: "Romascanu, Dan (Dan)" To: , Subject: [Netconf] FW: RFC 5381 on Experience of Implementing NETCONF over SOAP X-BeenThere: netconf@ietf.org X-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 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org Sent: Saturday, November 01, 2008 12:25 AM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: rfc-editor@rfc-editor.org Subject: RFC 5381 on Experience of Implementing NETCONF over SOAP A new Request for Comments is now available in online RFC libraries. RFC 5381 Title: Experience of Implementing NETCONF over SOAP Author: T. Iijima, Y. Atarashi, H. Kimura, M. Kitani, H. Okita Status: Informational Date: October 2008 Mailbox: tomoyuki.iijima@alaxala.com, atarashi@alaxala.net, h-kimura@alaxala.net, makoto.kitani@alaxala.com, hideki.okita.pf@hitachi.com Pages: 22 Characters: 47724 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-iijima-netconf-soap-implementation-10.txt URL: http://www.rfc-editor.org/rfc/rfc5381.txt This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF (Network Configuration Protocol) client and server. It describes an altan alternative SOAP binding for NETCONF that does not interoperate with an RFC 4743 conformant implementation making use of cookies on top of the persistent transport connections of HTTP. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ernative SOAP binding for NETCONF that does not interoperate with an RFC 4743 conformant implementation making use of cookies on top of the persistent transport connections of HTTP. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Nov 3 14:30: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 BBCFB28C346; Mon, 3 Nov 2008 14:30:06 -0800 (PST) X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A4E253A6B20; Mon, 3 Nov 2008 14:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103223001.A4E253A6B20@core3.amsl.com> Date: Mon, 3 Nov 2008 14:30:01 -0800 (PST) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-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 : NETCONF Monitoring Schema Author(s) : M. Scott, et al. Filename : draft-ietf-netconf-monitoring-03.txt Pages : 44 Date : 2008-11-03 This document defines NETCONF content via XML Schema to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF sessions, locks, and subscriptions and is intended to facilitate management of a NETCONF server. In addition this monitoring data provides clients with standardized content to describe supported schema. Today, NETCONF capabilities exchange is the only standardized method a client can use to discover the functionality supported by a NETCONF server. This works well for static protocol capabilities but is not well suited for capabilities which could change during a session. Considerations such as different schema formats, feature optionality and access controls can all impact the applicability and level of detail the NETCONF server sends to a client during session setup. Through updated monitoring data NETCONF clients can adjust their capabilities throughout a session. Specifically the details returned can be used by a client to determine whether retrieval of new schema information is required and includes the information required to facilitate the retrieval. A new RPC (get-schema) is also defined to support explicit schema retrieval via NETCONF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-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-monitoring-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03141936.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 Mon Nov 3 14:30: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 BBCFB28C346; Mon, 3 Nov 2008 14:30:06 -0800 (PST) X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A4E253A6B20; Mon, 3 Nov 2008 14:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103223001.A4E253A6B20@core3.amsl.com> Date: Mon, 3 Nov 2008 14:30:01 -0800 (PST) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-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 : NETCONF Monitoring Schema Author(s) : M. Scott, et al. Filename : draft-ietf-netconf-monitoring-03.txt Pages : 44 Date : 2008-11-03 This document defines NETCONF content via XML Schema to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF sessions, locks, and subscriptions and is intended to facilitate management of a NETCONF server. In addition this monitoring data provides clients with standardized content to describe supported schema. Today, NETCONF capabilities exchange is the only standardized method a client can use to discover the functionality supported by a NETCONF server. This works well for static protocol capabilities but is not well suited for capabilities which could change during a session. Considerations such as different schema formats, feature optionality and access controls can all impact the applicability and level of detail the NETCONF server sends to a client during session setup. Through updated monitoring data NETCONF clients can adjust their capabilities throughout a session. Specifically the details returned can be used by a client to determine whether retrieval of new schema information is required and includes the information required to facilitate the retrieval. A new RPC (get-schema) is also defined to support explicit schema retrieval via NETCONF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-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-monitoring-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03141936.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 Thu Nov 6 12:52:09 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 8BF463A6AB1; Thu, 6 Nov 2008 12:52:09 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E13813A6A9B for ; Thu, 6 Nov 2008 12:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.044 X-Spam-Level: * X-Spam-Status: No, score=1.044 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rz1rnI-10+U for ; Thu, 6 Nov 2008 12:52:07 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id E69433A6A28 for ; Thu, 6 Nov 2008 12:52:06 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1KyBpP-0001Wg-Ir for netconf@ietf.org; Thu, 06 Nov 2008 21:51:43 +0100 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Thu, 6 Nov 2008 21:50:54 +0100 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] Fw: [OPSAWG] start WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0584852837==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0584852837== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0266_01C94059.BE54DF30" This is a multi-part message in MIME format. ------=_NextPart_000_0266_01C94059.BE54DF30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable NETCONF WG members may be interested to take a look at this. It certainly makes sense to understand this in preparation of discussions w.r.t. data-types in the monitoring draft. Bert ----- Original Message -----=20 From: Scott O. Bradner=20 To: opsawg@ietf.org=20 Sent: Thursday, November 06, 2008 9:46 PM Subject: [OPSAWG] start WGLC on = draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt This message starts a WG Last Call on=20 draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt please express your opinions by December 5 thanks Ted & Scott _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ------=_NextPart_000_0266_01C94059.BE54DF30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
NETCONF WG members may be interested to take a look = at=20 this.
It certainly makes sense to understand this in = preparation=20 of
discussions w.r.t. data-types in the monitoring=20 draft.
 
Bert
----- Original Message -----=20
From: Scott O. = Bradner
Sent: Thursday, November 06, 2008 9:46 PM
Subject: [OPSAWG] start WGLC on=20 draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt


This message starts a WG Last Call on=20
draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt

please express = your=20 opinions by December 5

thanks

Ted &=20 Scott
_______________________________________________
OPSAWG = mailing=20 list
OPSAWG@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsawg

------=_NextPart_000_0266_01C94059.BE54DF30-- --===============0584852837== 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 --===============0584852837==-- From netconf-bounces@ietf.org Thu Nov 6 12:52:09 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 8BF463A6AB1; Thu, 6 Nov 2008 12:52:09 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E13813A6A9B for ; Thu, 6 Nov 2008 12:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.044 X-Spam-Level: * X-Spam-Status: No, score=1.044 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rz1rnI-10+U for ; Thu, 6 Nov 2008 12:52:07 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id E69433A6A28 for ; Thu, 6 Nov 2008 12:52:06 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1KyBpP-0001Wg-Ir for netconf@ietf.org; Thu, 06 Nov 2008 21:51:43 +0100 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Thu, 6 Nov 2008 21:50:54 +0100 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] Fw: [OPSAWG] start WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0584852837==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0584852837== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0266_01C94059.BE54DF30" This is a multi-part message in MIME format. ------=_NextPart_000_0266_01C94059.BE54DF30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable NETCONF WG members may be interested to take a look at this. It certainly makes sense to understand this in preparation of discussions w.r.t. data-types in the monitoring draft. Bert ----- Original Message -----=20 From: Scott O. Bradner=20 To: opsawg@ietf.org=20 Sent: Thursday, November 06, 2008 9:46 PM Subject: [OPSAWG] start WGLC on = draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt This message starts a WG Last Call on=20 draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt please express your opinions by December 5 thanks Ted & Scott _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ------=_NextPart_000_0266_01C94059.BE54DF30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
NETCONF WG members may be interested to take a look = at=20 this.
It certainly makes sense to understand this in = preparation=20 of
discussions w.r.t. data-types in the monitoring=20 draft.
 
Bert
----- Original Message -----=20
From: Scott O. = Bradner
Sent: Thursday, November 06, 2008 9:46 PM
Subject: [OPSAWG] start WGLC on=20 draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt


This message starts a WG Last Call on=20
draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt

please express = your=20 opinions by December 5

thanks

Ted &=20 Scott
_______________________________________________
OPSAWG = mailing=20 list
OPSAWG@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsawg

------=_NextPart_000_0266_01C94059.BE54DF30-- --===============0584852837== 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 --===============0584852837==-- From netconf-bounces@ietf.org Sun Nov 9 15:43:36 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 68CA83A6817; Sun, 9 Nov 2008 15:43:36 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B9983A6817 for ; Sun, 9 Nov 2008 15:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuuQDj+wng0Z for ; Sun, 9 Nov 2008 15:43:34 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id DABA93A6782 for ; Sun, 9 Nov 2008 15:43:33 -0800 (PST) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mA9NhRY12537 for ; Sun, 9 Nov 2008 23:43:27 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 9 Nov 2008 18:43:25 -0500 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC953E42@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-netconf-monitoring-03 Thread-Index: Ack+AkKH41J6J/e3R12XLxmHoIt/pQEwdLSA From: "Mark Scott" To: "netconf mailing list" Subject: [Netconf] FW: New Version Notification for draft-ietf-netconf-monitoring-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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, A new version of the NETCONF monitoring draft has been posted. It addresses comments received to date. The action item from IETF72 on definition of the IP address data type remains open. Discussion on that item to date and readiness for WGLC will be discussed at IETF73. Thank you for your comments. Mark -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Monday, November 03, 2008 5:20 PM To: Scott, Mark (CAR:2Y01) Cc: Chisholm, Sharon (CAR:ZZ00); mbj@tail-f.com Subject: New Version Notification for draft-ietf-netconf-monitoring-03 A new version of I-D, draft-ietf-netconf-monitoring-03.txt has been successfuly submitted by Mark Scott and posted to the IETF repository. Filename: draft-ietf-netconf-monitoring Revision: 03 Title: NETCONF Monitoring Schema Creation_date: 2008-11-03 WG ID: netconf Number_of_pages: 44 Abstract: This document defines NETCONF content via XML Schema to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF sessions, locks, and subscriptions and is intended to facilitate management of a NETCONF server. In addition this monitoring data provides clients with standardized content to describe supported schema. Today, NETCONF capabilities exchange is the only standardized method a client can use to discover the functionality supported by a NETCONF server. This works well for statiFrom netconf-bounces@ietf.org Sun Nov 9 15:43:36 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 68CA83A6817; Sun, 9 Nov 2008 15:43:36 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B9983A6817 for ; Sun, 9 Nov 2008 15:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuuQDj+wng0Z for ; Sun, 9 Nov 2008 15:43:34 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id DABA93A6782 for ; Sun, 9 Nov 2008 15:43:33 -0800 (PST) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mA9NhRY12537 for ; Sun, 9 Nov 2008 23:43:27 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 9 Nov 2008 18:43:25 -0500 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC953E42@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-netconf-monitoring-03 Thread-Index: Ack+AkKH41J6J/e3R12XLxmHoIt/pQEwdLSA From: "Mark Scott" To: "netconf mailing list" Subject: [Netconf] FW: New Version Notification for draft-ietf-netconf-monitoring-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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, A new version of the NETCONF monitoring draft has been posted. It addresses comments received to date. The action item from IETF72 on definition of the IP address data type remains open. Discussion on that item to date and readiness for WGLC will be discussed at IETF73. Thank you for your comments. Mark -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Monday, November 03, 2008 5:20 PM To: Scott, Mark (CAR:2Y01) Cc: Chisholm, Sharon (CAR:ZZ00); mbj@tail-f.com Subject: New Version Notification for draft-ietf-netconf-monitoring-03 A new version of I-D, draft-ietf-netconf-monitoring-03.txt has been successfuly submitted by Mark Scott and posted to the IETF repository. Filename: draft-ietf-netconf-monitoring Revision: 03 Title: NETCONF Monitoring Schema Creation_date: 2008-11-03 WG ID: netconf Number_of_pages: 44 Abstract: This document defines NETCONF content via XML Schema to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF sessions, locks, and subscriptions and is intended to facilitate management of a NETCONF server. In addition this monitoring data provides clients with standardized content to describe supported schema. Today, NETCONF capabilities exchange is the only standardized method a client can use to discover the functionality supported by a NETCONF server. This works well for static protc protocol capabilities but is not well suited for capabilities which could change during a session. Considerations such as different schema formats, feature optionality and access controls can all impact the applicability and level of detail the NETCONF server sends to a client during session setup. Through updated monitoring data NETCONF clients can adjust their capabilities throughout a session. Specifically the details returned can be used by a client to determine whether retrieval of new schema information is required and includes the information required to facilitate the retrieval. A new RPC (get-schema) is also defined to support explicit schema retrieval via NETCONF. The IETF Secretariat. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ocol capabilities but is not well suited for capabilities which could change during a session. Considerations such as different schema formats, feature optionality and access controls can all impact the applicability and level of detail the NETCONF server sends to a client during session setup. Through updated monitoring data NETCONF clients can adjust their capabilities throughout a session. Specifically the details returned can be used by a client to determine whether retrieval of new schema information is required and includes the information required to facilitate the retrieval. A new RPC (get-schema) is also defined to support explicit schema retrieval via NETCONF. The IETF Secretariat. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Nov 10 03:02:27 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 5BC4F3A6992; Mon, 10 Nov 2008 03:02:27 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2DF3A6992 for ; Mon, 10 Nov 2008 03:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.742 X-Spam-Level: X-Spam-Status: No, score=-5.742 tagged_above=-999 required=5 tests=[AWL=0.857, 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 xZzrtRXWPeoL for ; Mon, 10 Nov 2008 03:02:25 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id DA50D3A69E0 for ; Mon, 10 Nov 2008 03:02:24 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAAB2Jms001776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Nov 2008 12:02:19 +0100 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 mAAB2In7006844; Mon, 10 Nov 2008 12:02:19 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Nov 2008 12:01:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Nov 2008 12:01:30 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for IETF #73 NETCONF Session Thread-Index: Ack5TaSOWrKrjdEdSNSupJ4TNpGApQJzxIZg References: From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 10 Nov 2008 11:01:32.0513 (UTC) FILETIME=[B0C11510:01C94323] Subject: [Netconf] Agenda for IETF #73 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi All, we uploaded the updated agenda to the meeting material site. http://www.ietf.org/proceedings/08nov/agenda/netconf.txt We got only two volunteers for the 4741bis-draft, both of which are excellently capable: Juergen Schoenwaelder and Martin Bjorklund. We're happy that they have agreed to work as a team. The NETCONF WG session is on Monday, November 17, 2008, at 1740-1930. We would like to ask ALL PRESENTERS noted in the agenda to SEND their SLIDES to the co-chairs BY _Nov 15, 10pm CST_. The co-chairs need to check the slides before the session and provide them for the remote attendees early. Please also help to start the session on-time. If you volunteer to act as minute taker or jabber scribe please send us a note. The session cannot start before we are settled for this important positions. CFrom netconf-bounces@ietf.org Mon Nov 10 03:02:27 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 5BC4F3A6992; Mon, 10 Nov 2008 03:02:27 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2DF3A6992 for ; Mon, 10 Nov 2008 03:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.742 X-Spam-Level: X-Spam-Status: No, score=-5.742 tagged_above=-999 required=5 tests=[AWL=0.857, 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 xZzrtRXWPeoL for ; Mon, 10 Nov 2008 03:02:25 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id DA50D3A69E0 for ; Mon, 10 Nov 2008 03:02:24 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAAB2Jms001776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Nov 2008 12:02:19 +0100 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 mAAB2In7006844; Mon, 10 Nov 2008 12:02:19 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Nov 2008 12:01:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Nov 2008 12:01:30 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for IETF #73 NETCONF Session Thread-Index: Ack5TaSOWrKrjdEdSNSupJ4TNpGApQJzxIZg References: From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 10 Nov 2008 11:01:32.0513 (UTC) FILETIME=[B0C11510:01C94323] Subject: [Netconf] Agenda for IETF #73 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi All, we uploaded the updated agenda to the meeting material site. http://www.ietf.org/proceedings/08nov/agenda/netconf.txt We got only two volunteers for the 4741bis-draft, both of which are excellently capable: Juergen Schoenwaelder and Martin Bjorklund. We're happy that they have agreed to work as a team. The NETCONF WG session is on Monday, November 17, 2008, at 1740-1930. We would like to ask ALL PRESENTERS noted in the agenda to SEND their SLIDES to the co-chairs BY _Nov 15, 10pm CST_. The co-chairs need to check the slides before the session and provide them for the remote attendees early. Please also help to start the session on-time. If you volunteer to act as minute taker or jabber scribe please send us a note. The session cannot start before we are settled for this important positions. CU All U All in Minneapolis, Bert & Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf in Minneapolis, Bert & Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Nov 13 18:53: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 9FFD83A68A6; Thu, 13 Nov 2008 18:53:30 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6423A68A6 for ; Thu, 13 Nov 2008 18:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RqRfUjZjiNb for ; Thu, 13 Nov 2008 18:53:27 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id BCA993A688C for ; Thu, 13 Nov 2008 18:53:26 -0800 (PST) Received: from source ([66.129.228.6]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSRzoJhMiGUybP52ls0CfxU+rFn3+Lx/J@postini.com; Thu, 13 Nov 2008 18:53:27 PST Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Nov 2008 18:51:36 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Nov 2008 18:51:36 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 18:51:36 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mAE2pZM12149 for ; Thu, 13 Nov 2008 18:51:35 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id mAE2ke6n012632 for ; Fri, 14 Nov 2008 02:46:40 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200811140246.mAE2ke6n012632@idle.juniper.net> To: netconf@ietf.org Date: Thu, 13 Nov 2008 21:46:40 -0500 From: Phil Shafer X-OriginalArrivalTime: 14 Nov 2008 02:51:36.0226 (UTC) FILETIME=[E8DAA820:01C94603] Subject: [Netconf] partial-lock feedback X-BeenThere: netconf@ietf.org X-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 Here are some comments on the partial lock draft (-04). Thanks, Phil ----------- >1. Introduction > > The NETCONF protocol [NETCONF] describes the lock and unlock RPCs s/the// s/RPCs/operations/ ? > that operate on entire configuration datastores. Often, multiple > management sessions need to be able to modify the configuration of a > managed device in parallel. In these cases, locking only parts of a > configuration datastore is needed. This document defines an > extension to the NETCONF protocol to allow this. s/allow this/support partial locking of NETCONF datastores/ > The mechanism for partial locking is based on the existing XPath > filtering mechanisms. Or even: This document defines an extension to the NETCONF protocol to support partial locking of NETCONF datastores using a mechanism based on the existing XPath filtering mechanisms. > Partial locking is defined as a capability to NETCONF. Make this part of the the first paragraph, not out on its own. >2.1. Overview > > The :partial-lock capability indicates that the device supports the > locking of its configuration with a more limited scope than a > complete configuration datastore. The scope to be locked is > specified by using restricted or full XPath expressions. Partial > locking covers configuration data, but not state data. "covers" is a fuzzy word. You call out state data; should you also call out notification and rpc data? > The duration of the partial lock begins when the partial lock is > granted and lasts until (1) either the corresponding > operation succeeds or (2) the NETCONF session terminates. It seems odd to start using "<>"s here, and you are referring to an operation that you haven't introduced. I'd drop them and refer to the partial unlock operation in a more generic way. Or consider adding a paragraph describing the basic operation, how they work, and what they are used for. An overview like this would be helpful to the reader. In NETCONF, the locks are short duration, meant to allow the client to grab it, change the config, and release it. Are partial lock similar? Do you need to say something about the operating model for partial locks? Did you consider simply extending the arguments to the existing lock/unlock operations rather than creating new ones? As NETCONF matures, adding new ops will be less attractive, since it means increasing the work required to add new features. For example, if I supported a capability that added a new argument to , I would now have to introduce another new capability to add this to . Better to :partial add / or /"select"/ Otherwise is reads like "the select elements" means some special elements. Same for . You have multiple expression only once, at the time the lock is granted. Once the lock is granted, changes to the database to not affect the scope of the lock. Adding a concrete example would be good. In general, this draft needs more examples. People love examples. And parfait. > Thereafter, the scope of the lock is maintained as a set of nodes. Do you ever define "scope"? It's a fuzzy term, so if you want to use it, please define it in crisp terms. > If the configuration data is later altered in a way that would make > the original select XPath expressions evaluate to a different set of > nodes, this does not affect the scope of the partial lock. > > XPath is only used for the creation of the partial lock. > Conceptually, the scope of the lock is defined by the returned node > set and not by the XPath expression. These paragraphs seem to dance around some point that's not clear. What to you mean "conceptually ... not by the xpath"? Why doesn't the XPath expression tell you want you're trying to lock? > A operation MUST be handled atomically by the NETCONF > server. The server either locks all requested parts of the > datastore(s) or none. That is, if during the s/That is, if/If/ > operation one of the requested parts cannot be locked, the server > MUST unlock all parts that were previously locked during that s/all/any/? > operation. This last sentence is unclear (or evil). "previously locked during" includes anything I had locked from previous lock requests, which isn't what you want. This whole issue makes me wonder why you need to support multiple s is inconsistent. You also need to think about what it would look like if we make an identity called "datastore" in 4741-bis and folks extend it with or or . When they want to lock multiple files, how will it work? > select: One or more 'select' elements, each containing an XPath > expression.... > Each select expression is evaluated for each targeted datastore. Seems like this paragraph needs more words. > The nodes that matched the select expression and are locked are > reported in the rpc-reply message. Make one paragraph on locked and a different one on reporting. Mixing different topics in one paragraph is hard for the reader (and worse for the skimmer). I strongly dislike the idea of reporting what was locked in the reply. This is mostly useless information and will be annoying to generate with proper namespace mappings. What is the win in reporting to the client the information the client just sent to you? > Note that if some of the > requested nodes exist only in one of the datastores, the lock is > granted on different nodes in different datastores. Don't hide "Note"s in unrelated paragraphs. Remember that most readers skim, reading the topic sentence and then skipping the rest of the paragraph if they (a) assume they know what you are going to say, or (b) thing this paragraph doesn't interest them. Allow the same lines, there are placing when you can consolidate all the text about an issue in one spot instead of interlacing the text with other topics. > Each select expression MUST return a node set, and at least one > of the node sets for one of the specified datastores MUST be non- > empty. Is this done to catch errors? I don't understand how this helps. > If the device supports the :xpath capability, any valid XPath 1.0 > expression can be used. If the device does not support the > :xpath capability, the XPath expression MUST be limited to an > Instance Identifier expression. An Instance Identifier is an > absolute path expression in abbreviated syntax, where predicates > are used only to specify values for nodes defined as keys to > distinguish multiple instances. Is the term "Instance Identifier" local to this draft? If so, maybe it's time to make a "Terminology" section. At a minimum, it needs a more complete definition. Is it worthwhile to put XPath expressions into a distinct argument? .vs. and multiple s to the existing RPC. > A NETCONF session MAY have multiple parts of one or more datastores > (running, candidate, startup) locked using partial lock operations. > The operation returns a lock-id to identify each > successfully acquired lock. These two sentences are unrelated. >2.2. Dependencies > > The device MUST support restricted XPath expressions in the select > element, as described in Section 2.4.1. Optionally, if the :xpath > capability is also supported, the device MUST also support using any > XPath 1.0 expression in the select element. Put a reference on :xpath so we know you are talking about the base NETCONF :xpath capability. Would it work better of "xpath" were a "feature" (in the YANG sense) of this model, rather than forcing folks that want :xpath in the base netconf ops to support it here? Having this implicit behavior is a bad thing. >2.4.1. > > The operation allows the client to lock a portion of > one or more datastores. The portion to lock is specified with XPath > expressions in the select elements and the list of datastores in the > target element in the operation. s/select/ elements and one element containing multiple values. This is inconsistent. Change target to a leaf-list of enums. > Each XPath > expression MUST return a node set. This is an odd sentence. What are you trying to say? Are you worried that someone will think you mean predicate expressions? Do you want to explicit reference the XPath spec'c production name (LocationPath in section 2.0 of http://www.w3.org/TR/xpath.html). > Locking a node also protects the > complete subtree under the node from modification by others. This is a very important concept that needs to be brought out. When you lock a node, you lock it and its children. No one can modify any child of a node you lock. This may be obvious, but it needs to be said clearly. > In some situations it is desirable that the same set of nodes are > locked in more than one datastore. As an example: if an interface is s/As an example:/For example,/ > configured in the candidate datastore, it is dangerous if it is s/if it is/for it to be/ > configured by someone else in a possibly conflicting manner in the > running datastore. For this reason allows the locking > of the same sections of the management data in one or multiple > datastores. s/one or// Locking multiple datastores requires maximally pessimistic lock use, right? I MUST lock it everywhere to protect myself. Seems pointless. There's some logic that says the intersection of boxes with :writable-running and :candidate is (or should be) nil. So you should only need to lock one or the other. > The select XPath expressions are evaluated only once at lock time. "select XPath expressions" is an odd phrase. NETCONF servers evaluate each expressions, instead of making the client "OR" them together. Where's the win? > If a node is locked by a session, only that same session is able to > modify that node or any node in the subtree underneath it. When a NETCONF session holds a lock on a node, no other session or non-NETCONF mechanism of the system can change that node or any node in the hierarchy of nodes beneath it. Merge this with the related text above (where I said this point needs to be more strongly made). > If a top level node of a locked subtree is deleted, any other session > can recreate it, as it is no longer covered by the lock. If all top > level nodes are deleted, the lock will still be present. However, > its scope will become nil (i.e., the lock will not cover any nodes). s/ nil (i.e., the/empty (since/ "cover" and "scope" are fuzzy. Define them and how they relate. (But I think with better wording you can avoid these terms). Nodes are released from the lock when they are deleted, at which point other clients or non-NETCONF mechanisms are able to recreate them. > A NETCONF server MUST be able to grant multiple simultaneous partial > locks to a single NETCONF session. If the scope of the individual > locks overlaps, nodes in the common area MUST be locked until all of > the locks are released. Nodes locked under multiple overlapping locks remain locked until all such locks are released. > A partial lock operation MUST fail if: > > o Any NETCONF session (including the current session) owns the > global lock on any target datastore. > > o Any part of the scope to be locked is already locked by another > management session/protocol, including other NETCONF sessions > using the or any other non-NETCONF management > method. > > o The NETCONF server implements access control, and the locking user > does not have sufficient rights to all parts of a datastore > section to be locked. The NETCONF server's access control mechanism does not give the locking user sufficient rights to any nodes to be locked. > The exact handling of access rights is > outside the scope of this document, but it is assumed that there > is an access control system that MAY deny or allow the partial > lock operation. > > Two blank lines? > As with most locking systems, it is possible that two management > sessions trying to lock different parts of the configuration could > become dead-locked. To avoid this situation, clients SHOULD lock > everything they need in one operation. If that operation fails, the > client SHOULD back down, release any previously acquired locks, and > retry the procedure after waiting some time interval. The length of > the interval SHOULD be random to avoid repeated dead-locks when both > (or all) clients back down and then retry the partial lock operation. Need a "Deadlock Avoidance" section. "back down" is a fuzzy concept. If you want exponential back-off, say so. s/dead-lock/deadlock/ > The operation is designed for simplicity, so when a > partial lock is executed you get what you asked for: a set of nodes > that are locked for writing. There are some other issues that are > intentionally not addressed: "not addressed"? Hogwash. Address them. > o Locking does not affect read operations. Address it: Say "Locking does not affect read operations". > o If part of a datastore is locked, this has no effect on any > unlocked parts of the datastore. If this is a problem (e.g., > changes depend on data values in the unlocked part of the > datastore), these values SHOULD be included in the scope of the > lock. s/values/nodes/ s/SHOULD/should/ since this is not a requirement of the specification. Address it: If the client should not attempting operations that rely on configuration that is not locked. > o Configuration data can be edited both inside and outside the scope > of a lock. It is the responsibility of the NETCONF client > application to lock all relevant parts of a datastore that are > crucial for a specific management action. Address it. This is a big point and should be in a list of "things we didn't address". > Note: The operation does not modify the global > operation defined in the base NETCONF Protocol [NETCONF]. If part of > a datastore is already locked by , then a global lock > for that datastore MUST fail even if the global lock is requested by > the NETCONF session that owns the partial lock. Make a section on "Interactions with and ", so this is more visible to the reader (and in the table of contents). >2.4.1.1. Parameters, Result, Examples > > Parameters: > > target: Name of one or more configuration datastores of which a part > shall be locked. If multiple datastores are specified the same > select parameter(s) are used for all of them. For each datastore > locking of the same set of nodes will be requested. "same set of nodes": it won't be the same set of nodes if the datastores have different contents. I mentioned before that having one will multiple contents and multiple ? > Positive Response: > If the device was able to satisfy the request, an is sent > with a element (lock identifier) in the > element. A list of locked nodes per datastore is also returned in > Instance Identifier format. So if I lock all sonet interfaces, I get a list of all sonet interfaces? When do I need this? > Negative Response: > If a lock is already held by another session on any node within the > subtrees to be locked, the element is 'lock-denied' and > the element includes the of the lock owner. > If the lock is held by a non-NETCONF session, a of 0 > (zero) is included. If needed the returned session-id may be used to > the NETCONF session holding the lock. The same error > response is returned if the requesting session already holds the > (global) lock for the same datastore. If global locks are the same, merge their handling into the text. If a partial lock is already held by another session on any node within the subtrees to be locked or a global lock is held by any NETCONF client, the element is 'lock-denied' and... > If all the select expressions return an empty node set, the tag> is 'operation-failed', and the is 'no-matches'. Why is this app-tag have dashes but the other's don't? "no matches". > If any select expression returns something other than a node set, the > is 'invalid-value', the is 'XPath does > not return a node set'. How can the expression return something other than a node set? > If the :xpath capability is not supported and the XPath expression is > not an Instance Identifier, the is 'invalid-value', the > is ':xpath capability not supported'. Show some love to your users: "invalid lock specification" > If access control denies the partial lock, the is > 'access-denied'. "access denied". >2.4.1.2. Reserving model sections for future work This is a poor title. "Locking nodes before they are created"? > Partial lock cannot be used to lock non-existent nodes, which would > effectively attempt to reserve them for future use. To guarantee > that a node cannot be created by some other session, the parent node > SHOULD be locked, the top level node of the new section created, and > then locked with another operation. After this, the > lock on the parent node SHOULD be removed. Since partial locks cannot be taken out for nodes that do not exist, special handling is required on the client to handle scenarios the locking of newly created nodes. To guarantee ... >2.4.2. > > The operation unlocks the parts of the datastores that were > previously locked using during the same session. > > Parameters: > > lock-id: Lock identifier to unlock, taken from a reply to a previous > operation. This lock-id MUST have been received as a response to a lock request by the NETCONF server during the current session, and MUST NOT have been sent in a previous unlock request. >2.5. Modifications to Existing Operations > > A successful partial lock will cause a subsequent operation to fail > if it attempts to modify the locked area and is executed in a NETCONF > session other than the session that owns the lock. Fail with what error? s/owns/has been granted/ "locked area" is a new term. > All operations > that modify the datastore are affected, including: , > , , and . A > successful partial lock will also cause the (global) operation > to fail. All of these operations are affected only if they are > targeting the same datastore. "successful" here is confusing. You make it sound like the partial-lock operation will cause a to fail, rather than the existence of locked nodes. ? You can't commit it someone else has a partial lock? I think you need to put more words into what operations are not allowed. I know it sounds trivial to say it, but are things like insert allowed? >2.6.2. Confirmed Commit Capability > > If: > > > > >Lengyel & Bjorklund Expires May 2, 2009 [Page 9] > >Internet-Draft Partial Lock RPC for NETCONF October 2008 This "If:" is a _horrible_ case of hanging text. I think this can be avoided completely if you rephrase the text a bit: If the NETCONF server supports the :confirmed-commit capability and a confirmed commit is outstanding, partial lock requests for the database MUST be denied, since the running datastore must be rolled back if a confirming commit is not performed within the appropriate time window. > In this case the 'in-use' and the 'Lock > denied, Outstanding confirmed commit' is returned. Can we please use lower case for app-tag values? >2.6.3. Distinct Startup Capability > Partial locking of the startup datastore can only be done if the > :startup capability is supported by the device. :startup is not a valid target for , so it should not be a target for partial locks. >3. Security Considerations >... > Partial locking is NOT an authorization mechanism; it SHOULD NOT be > used to provide security or access control. Partial locking SHOULD > only be used as a mechanism for providing consistency when multiple > managers are trying to configure the node. It is vital that users > easily understand the exact scope of a lock. This is why the scope > is determined when granting a lock and is not modified thereafter. "users"? Users understand XPaths expressions? "exact scope"? I don't get this argument. The way you've got this working, not one can understand the exact scope of a lock. If I lock all sonet interfaces, no one without a log file and a crystal ball will be able to tell me which sonet interfaces I have locked. Any interfaces created after I got my lock aren't locked. Anything I deleted and someone (even me) recreated isn't locked. If you are looking for exactness and understandability, you need to rethink this. >5. Appendix A - XML Schema for Partial Locking (normative) For the record, I didn't read this section. >6. Appendix B - YANG Module for Partial Locking (non-normative) > module netconf-partial-lock { s/netconf/ietf-netconf/ IETF YANG modules should all start with "ietf-". > grouping configNames { Should this be an identify? > container target { > description > "A list of one or more datastore names."; > leaf running { type empty; } > leaf candidate { type empty; } > leaf startup { type empty; } Add if-features for :writable-running, :candidate, and :startup. > leaf-list select { > description > "XPath expression that specifies the scope of the lock. > An Instance Identifier expression MUST be used unless the > :xpath capability is supported, in which case any XPath 1.0 > expression is allowed."; > type string; We should have a typedef for XPath expressions (locationPath). > output { > leaf lock-id { > description > "Identifies the lock, if granted. The lock-id MUST be > used in the partial-unlock rpc."; MUST? I can do my change and then terminate my connection without doing a partial-unlock. > type uint32; This should be a typedef. ------------------- _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Nov 13 19: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 5062B3A6884; Thu, 13 Nov 2008 19:32:40 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2BC93A6884 for ; Thu, 13 Nov 2008 19:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.919 X-Spam-Level: * X-Spam-Status: No, score=1.919 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpGFxhOvwaGi for ; Thu, 13 Nov 2008 19:32:38 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 01F5D3A657C for ; Thu, 13 Nov 2008 19:32:38 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAB001UQ0I45Z@szxga03-in.huawei.com> for netconf@ietf.org; Fri, 14 Nov 2008 11:32:28 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAB00LLW0I4QA@szxga03-in.huawei.com> for netconf@ietf.org; Fri, 14 Nov 2008 11:32:28 +0800 (CST) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Fri, 14 Nov 2008 11:32:06 +0800 Date: Fri, 14 Nov 2008 11:32:06 +0800 From: Washam Fan To: netconf@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: zh-CN Content-disposition: inline X-Accept-Language: zh-CN Priority: normal Subject: [Netconf] How to understand Event Stream in RFC5277 X-BeenThere: netconf@ietf.org X-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, Could anybody give me some example criteria for categorizing Event Stream? The example in section 3.2.5.1 show us NETCONF Event Stream, SNMP Event Stream and syslog-critical Event Stream, do Event Streams categorized base on their sources? I recognize this is not right moment to issue such a question. But I want you help. Thanks in advance Regards, Washam _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Nov 13 19: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 5062B3A6884; Thu, 13 Nov 2008 19:32:40 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2BC93A6884 for ; Thu, 13 Nov 2008 19:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.919 X-Spam-Level: * X-Spam-Status: No, score=1.919 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpGFxhOvwaGi for ; Thu, 13 Nov 2008 19:32:38 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 01F5D3A657C for ; Thu, 13 Nov 2008 19:32:38 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAB001UQ0I45Z@szxga03-in.huawei.com> for netconf@ietf.org; Fri, 14 Nov 2008 11:32:28 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAB00LLW0I4QA@szxga03-in.huawei.com> for netconf@ietf.org; Fri, 14 Nov 2008 11:32:28 +0800 (CST) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Fri, 14 Nov 2008 11:32:06 +0800 Date: Fri, 14 Nov 2008 11:32:06 +0800 From: Washam Fan To: netconf@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: zh-CN Content-disposition: inline X-Accept-Language: zh-CN Priority: normal Subject: [Netconf] How to understand Event Stream in RFC5277 X-BeenThere: netconf@ietf.org X-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, Could anybody give me some example criteria for categorizing Event Stream? The example in section 3.2.5.1 show us NETCONF Event Stream, SNMP Event Stream and syslog-critical Event Stream, do Event Streams categorized base on their sources? I recognize this is not right moment to issue such a question. But I want you help. Thanks in advance Regards, Washam _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Nov 16 11:42: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 E16743A6918; Sun, 16 Nov 2008 11:42:44 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 072C63A6918 for ; Sun, 16 Nov 2008 11:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FiRW3ge6pMT for ; Sun, 16 Nov 2008 11:42:43 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 0E5523A6358 for ; Sun, 16 Nov 2008 11:42:42 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id mAGJdUI11368; Sun, 16 Nov 2008 19:39:31 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 16 Nov 2008 14:42:38 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4173FF9FA@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] How to understand Event Stream in RFC5277 Thread-Index: AclGCaq/1pMaKowRQqGc/JzB5T1GuACGOn4w References: From: "Sharon Chisholm" To: "Washam Fan" , Subject: Re: [Netconf] How to understand Event Stream in RFC5277 X-BeenThere: netconf@ietf.org X-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 That was one example use that had been suggested in working group discussions, although not one we currently use. One use I think is interesting is to create streams based on the type of information as a sort of pre-defined set of filters - configuration change events, faults, etc. The actual use of streams we've actually used is to define a stream with a different aging criteria than the default stream. Rather than just being time based, a replay of that stream only replays Notifications that are still relevant. Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Washam Fan Sent: Thursday, November 13, 2008 10:32 PM To: netconf@ietf.org Subject: [Netconf] How to understand Event Stream in RFC5277 Hi, Could anybody give me some example criteria for categorizing Event Stream? The example in section 3.2.5.1 show us NETCONF Event Stream, SNMP Event Stream and syslog-critical Event Stream, do Event Streams categorized base on their sources? I recognize this is not right moment to issue such a question. But I want you help. Thanks in advance Regards, Washam _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https:/From netconf-bounces@ietf.org Sun Nov 16 11:42: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 E16743A6918; Sun, 16 Nov 2008 11:42:44 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 072C63A6918 for ; Sun, 16 Nov 2008 11:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FiRW3ge6pMT for ; Sun, 16 Nov 2008 11:42:43 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 0E5523A6358 for ; Sun, 16 Nov 2008 11:42:42 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id mAGJdUI11368; Sun, 16 Nov 2008 19:39:31 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 16 Nov 2008 14:42:38 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4173FF9FA@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] How to understand Event Stream in RFC5277 Thread-Index: AclGCaq/1pMaKowRQqGc/JzB5T1GuACGOn4w References: From: "Sharon Chisholm" To: "Washam Fan" , Subject: Re: [Netconf] How to understand Event Stream in RFC5277 X-BeenThere: netconf@ietf.org X-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 That was one example use that had been suggested in working group discussions, although not one we currently use. One use I think is interesting is to create streams based on the type of information as a sort of pre-defined set of filters - configuration change events, faults, etc. The actual use of streams we've actually used is to define a stream with a different aging criteria than the default stream. Rather than just being time based, a replay of that stream only replays Notifications that are still relevant. Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Washam Fan Sent: Thursday, November 13, 2008 10:32 PM To: netconf@ietf.org Subject: [Netconf] How to understand Event Stream in RFC5277 Hi, Could anybody give me some example criteria for categorizing Event Stream? The example in section 3.2.5.1 show us NETCONF Event Stream, SNMP Event Stream and syslog-critical Event Stream, do Event Streams categorized base on their sources? I recognize this is not right moment to issue such a question. But I want you help. Thanks in advance Regards, Washam _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org h/www.ietf.org/mailman/listinfo/netconf ttps://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Nov 17 12:26: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 9B33E3A6A59; Mon, 17 Nov 2008 12:26:46 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2E63A6A56 for ; Mon, 17 Nov 2008 12:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u827gNCKeOii for ; Mon, 17 Nov 2008 12:26:43 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 73C783A6876 for ; Mon, 17 Nov 2008 12:26:42 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9FACE200A8 for ; Mon, 17 Nov 2008 21:26:40 +0100 (CET) X-AuditID: c1b4fb3e-aff88bb00000537b-33-4921d3806abf Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 75939204C6 for ; Mon, 17 Nov 2008 21:26:40 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Nov 2008 21:26:40 +0100 Received: from [127.0.0.1] ([159.107.197.237]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Nov 2008 21:26:39 +0100 Message-ID: <4921D383.2080102@ericsson.com> Date: Mon, 17 Nov 2008 21:26:43 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf@ietf.org References: <200811140246.mAE2ke6n012632@idle.juniper.net> In-Reply-To: <200811140246.mAE2ke6n012632@idle.juniper.net> X-OriginalArrivalTime: 17 Nov 2008 20:26:39.0654 (UTC) FILETIME=[CBE07460:01C948F2] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] partial-lock feedback X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: balazs.lengyel@ericsson.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Phil, Thanks for the comments. See my replies below. Tell me if I missed anything. Balazs Phil Shafer wrote: > Here are some comments on the partial lock draft (-04). > > Thanks, > Phil > > > ----------- > >> 1. Introduction >> >> The NETCONF protocol [NETCONF] describes the lock and unlock RPCs > > s/the// > s/RPCs/operations/ ? OK > >> that operate on entire configuration datastores. Often, multiple >> management sessions need to be able to modify the configuration of a >> managed device in parallel. In these cases, locking only parts of a >> configuration datastore is needed. This document defines an >> extension to the NETCONF protocol to allow this. > > s/allow this/support partial locking of NETCONF datastores/ > >> The mechanism for partial locking is based on the existing XPath >> filFrom netconf-bounces@ietf.org Mon Nov 17 12:26: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 9B33E3A6A59; Mon, 17 Nov 2008 12:26:46 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2E63A6A56 for ; Mon, 17 Nov 2008 12:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u827gNCKeOii for ; Mon, 17 Nov 2008 12:26:43 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 73C783A6876 for ; Mon, 17 Nov 2008 12:26:42 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9FACE200A8 for ; Mon, 17 Nov 2008 21:26:40 +0100 (CET) X-AuditID: c1b4fb3e-aff88bb00000537b-33-4921d3806abf Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 75939204C6 for ; Mon, 17 Nov 2008 21:26:40 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Nov 2008 21:26:40 +0100 Received: from [127.0.0.1] ([159.107.197.237]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Nov 2008 21:26:39 +0100 Message-ID: <4921D383.2080102@ericsson.com> Date: Mon, 17 Nov 2008 21:26:43 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf@ietf.org References: <200811140246.mAE2ke6n012632@idle.juniper.net> In-Reply-To: <200811140246.mAE2ke6n012632@idle.juniper.net> X-OriginalArrivalTime: 17 Nov 2008 20:26:39.0654 (UTC) FILETIME=[CBE07460:01C948F2] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] partial-lock feedback X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: balazs.lengyel@ericsson.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Phil, Thanks for the comments. See my replies below. Tell me if I missed anything. Balazs Phil Shafer wrote: > Here are some comments on the partial lock draft (-04). > > Thanks, > Phil > > > ----------- > >> 1. Introduction >> >> The NETCONF protocol [NETCONF] describes the lock and unlock RPCs > > s/the// > s/RPCs/operations/ ? OK > >> that operate on entire configuration datastores. Often, multiple >> management sessions need to be able to modify the configuration of a >> managed device in parallel. In these cases, locking only parts of a >> configuration datastore is needed. This document defines an >> extension to the NETCONF protocol to allow this. > > s/allow this/support partial locking of NETCONF datastores/ > >> The mechanism for partial locking is based on the existing XPath >>tering mechanisms. > > Or even: > > This document defines an extension to the NETCONF protocol to > support partial locking of NETCONF datastores using a mechanism > based on the existing XPath filtering mechanisms. OK > >> Partial locking is defined as a capability to NETCONF. > > Make this part of the the first paragraph, not out on its own. OK > >> 2.1. Overview >> >> The :partial-lock capability indicates that the device supports the >> locking of its configuration with a more limited scope than a >> complete configuration datastore. The scope to be locked is >> specified by using restricted or full XPath expressions. Partial >> locking covers configuration data, but not state data. > > "covers" is a fuzzy word. OK, will reword: Partial locking affects configuration data but not state data. > > You call out state data; should you also call out notification and > rpc data? What is the meaning of locking rpc or a notification? It does not exist for a prolonged time, so what does it mean that it doesn't changed. I don't think this is needed. > >> The duration of the partial lock begins when the partial lock is >> granted and lasts until (1) either the corresponding >> operation succeeds or (2) the NETCONF session terminates. > > It seems odd to start using "<>"s here, and you are referring to an > operation that you haven't introduced. I'd drop them and refer to the > partial unlock operation in a more generic way. OK > > Or consider adding a paragraph describing the basic operation, how > they work, and what they are used for. An overview like this would be > helpful to the reader. > > In NETCONF, the locks are short duration, meant to allow the client to > grab it, change the config, and release it. Are partial lock similar? > Do you need to say something about the operating model for partial > locks? No we want to minimize describing intended usage. > > Did you consider simply extending the arguments to the existing > lock/unlock operations rather than creating new ones? As NETCONF > matures, adding new ops will be less attractive, since it means > increasing the work required to add new features. For example, if I > supported a capability that added a new argument to > , I would now have to introduce another new capability to > add this to . Better to :partial add and > multiple s to the existing RPC. We do not want some of the logic connected to global locking to apply for partial-lock: e.g. special rules for handling the candidate datastore. As an aside: I think there are not so many operations that we need to worry about their number. RC4741 does not allow extending the lock requirement (We might be argument about this, but this is the current situation.). > >> A NETCONF session MAY have multiple parts of one or more datastores >> (running, candidate, startup) locked using partial lock operations. >> The operation returns a lock-id to identify each >> successfully acquired lock. > > These two sentences are unrelated. OK, put them in separate paragraphs. > >> 2.2. Dependencies >> >> The device MUST support restricted XPath expressions in the select >> element, as described in Section 2.4.1. Optionally, if the :xpath >> capability is also supported, the device MUST also support using any >> XPath 1.0 expression in the select element. > > Put a reference on :xpath so we know you are talking about the base > NETCONF :xpath capability. Would it work better of "xpath" were a > "feature" (in the YANG sense) of this model, rather than forcing folks > that want :xpath in the base netconf ops to support it here? Having > this implicit behavior is a bad thing. OK, will include reference. NO for separate feature, because - it is more simple and consistent if you have just one switch per box that describes the XPath support by an agent: the XPath capability. - notification uses the capability for the same purpose, it would be confusing to use something different here - want to avoid to many options and features - feature is a YANG construct that is not yet ready > >> 2.4.1. >> >> The operation allows the client to lock a portion of >> one or more datastores. The portion to lock is specified with XPath >> expressions in the select elements and the list of datastores in the >> target element in the operation. > > s/select/ elements and one element > containing multiple values. This is inconsistent. Change > target to a leaf-list of enums. We must settle on the encoding. I think both solutions are OK. Some people wanted the target wrapper. We will ask the group. > >> Each XPath >> expression MUST return a node set. > > This is an odd sentence. What are you trying to say? Are you worried > that someone will think you mean predicate expressions? Do you want > to explicit reference the XPath spec'c production name (LocationPath > in section 2.0 of http://www.w3.org/TR/xpath.html). An XPath expression can return a node set, a boolean, a number or a string (see section 1. in http://www.w3.org/TR/xpath). > >> Locking a node also protects the >> complete subtree under the node from modification by others. > > This is a very important concept that needs to be brought out. When > you lock a node, you lock it and its children. No one can modify any > child of a node you lock. This may be obvious, but it needs to be > said clearly. OK, make it a separte paragraph. > >> In some situations it is desirable that the same set of nodes are >> locked in more than one datastore. As an example: if an interface is > > s/As an example:/For example,/ OK > >> configured in the candidate datastore, it is dangerous if it is > > s/if it is/for it to be/ OK > >> configured by someone else in a possibly conflicting manner in the >> running datastore. For this reason allows the locking >> of the same sections of the management data in one or multiple >> datastores. > > s/one or// OK > > Locking multiple datastores requires maximally pessimistic lock use, > right? I MUST lock it everywhere to protect myself. Seems > pointless. There's some logic that says the intersection of > boxes with :writable-running and :candidate is (or should be) nil. > So you should only need to lock one or the other. It is not stated anywhere that you can't have candidate and writable-running together. So give pessimists some tools. > >> The select XPath expressions are evaluated only once at lock time. > > "select XPath expressions" is an odd phrase. OK I will change it to "The XPath expressions". > > NETCONF servers evaluate each expressions, instead of making the client "OR" them > together. OR would return a boolean We believe it is more clear to use multiple smaller expressions then one big one. (We had the same argument for tang-types.) > >> If a node is locked by a session, only that same session is able to >> modify that node or any node in the subtree underneath it. > > When a NETCONF session holds a lock on a node, no other session or > non-NETCONF mechanism of the system can change that node or any node > in the hierarchy of nodes beneath it. OK > > Merge this with the related text above (where I said this point needs > to be more strongly made). Its needed here as well. > >> If a top level node of a locked subtree is deleted, any other session >> can recreate it, as it is no longer covered by the lock. If all top >> level nodes are deleted, the lock will still be present. However, >> its scope will become nil (i.e., the lock will not cover any nodes). > > s/ nil (i.e., the/empty (since/ OK > > "cover" and "scope" are fuzzy. Define them and how they relate. (But > I think with better wording you can avoid these terms). OK rephrase. > > Nodes are released from the lock when they are deleted, at which > point other clients or non-NETCONF mechanisms are able to recreate them. > >> A NETCONF server MUST be able to grant multiple simultaneous partial >> locks to a single NETCONF session. If the scope of the individual >> locks overlaps, nodes in the common area MUST be locked until all of >> the locks are released. > > Nodes locked under multiple overlapping locks remain locked until > all such locks are released. Less clear, it does not state that partial locks MAY overlap. > >> A partial lock operation MUST fail if: >> >> o Any NETCONF session (including the current session) owns the >> global lock on any target datastore. >> >> o Any part of the scope to be locked is already locked by another >> management session/protocol, including other NETCONF sessions >> using the or any other non-NETCONF management >> method. >> >> o The NETCONF server implements access control, and the locking user >> does not have sufficient rights to all parts of a datastore >> section to be locked. > > The NETCONF server's access control mechanism does not give the > locking user sufficient rights to any nodes to be locked. OK, but is this really better? > >> The exact handling of access rights is >> outside the scope of this document, but it is assumed that there >> is an access control system that MAY deny or allow the partial >> lock operation. >> >> > > Two blank lines? OK, remove one. > >> As with most locking systems, it is possible that two management >> sessions trying to lock different parts of the configuration could >> become dead-locked. To avoid this situation, clients SHOULD lock >> everything they need in one operation. If that operation fails, the >> client SHOULD back down, release any previously acquired locks, and >> retry the procedure after waiting some time interval. The length of >> the interval SHOULD be random to avoid repeated dead-locks when both >> (or all) clients back down and then retry the partial lock operation. > > Need a "Deadlock Avoidance" section. No with don't want to make this into a tutorial. > > "back down" is a fuzzy concept. If you want want exponential back-off, say so. OK, reword. > > s/dead-lock/deadlock/ OK > >> The operation is designed for simplicity, so when a >> partial lock is executed you get what you asked for: a set of nodes >> that are locked for writing. There are some other issues that are >> intentionally not addressed: > > "not addressed"? Hogwash. Address them. Misunderstanding. We will rephrase. The issues ARE addressed in the following paragraphs. These paragraphs rather describe items that are out of scope. > >> o Locking does not affect read operations. > > Address it: Say "Locking does not affect read operations". It is stated. > >> o If part of a datastore is locked, this has no effect on any >> unlocked parts of the datastore. If this is a problem (e.g., >> changes depend on data values in the unlocked part of the >> datastore), these values SHOULD be included in the scope of the >> lock. > > s/values/nodes/ OK > > s/SHOULD/should/ since this is not a requirement of the specification. OK > > Address it: If the client should not attempting operations that rely > on configuration that is not locked. We don't want to state more, this is not a tutorial. > >> o Configuration data can be edited both inside and outside the scope >> of a lock. It is the responsibility of the NETCONF client >> application to lock all relevant parts of a datastore that are >> crucial for a specific management action. > > Address it. This is a big point and should be in a list of "things we > didn't address". > >> Note: The operation does not modify the global >> operation defined in the base NETCONF Protocol [NETCONF]. If part of >> a datastore is already locked by , then a global lock >> for that datastore MUST fail even if the global lock is requested by >> the NETCONF session that owns the partial lock. > > Make a section on "Interactions with and ", so this is > more visible to the reader (and in the table of contents). It would be unusual to have a separate section on all the things we do not modify. > >> 2.4.1.1. Parameters, Result, Examples >> >> Parameters: >> >> target: Name of one or more configuration datastores of which a part >> shall be locked. If multiple datastores are specified the same >> select parameter(s) are used for all of them. For each datastore >> locking of the same set of nodes will be requested. > > "same set of nodes": it won't be the same set of nodes if the > datastores have different contents. OK remove last sentence. > > I mentioned before that having one will multiple contents and > multiple / or /"select"/ > Otherwise is reads like "the select elements" means some special > elements. Same for . OK > > You have multiple expression only once, at > the time the lock is granted. Once the lock is granted, changes > to the database to not affect the scope of the lock. > > Adding a concrete example would be good. In general, this draft needs > more examples. People love examples. And parfait. ???? > >> Thereafter, the scope of the lock is maintained as a set of nodes. > > Do you ever define "scope"? It's a fuzzy term, so if you want to use > it, please define it in crisp terms. OK. Add to terms: Scope of the lock: set of nodes returned by the XPath expressions in a successful partial-lock operation. >> If the configuration data is later altered in a way that would make >> the original select XPath expressions evaluate to a different set of >> nodes, this does not affect the scope of the partial lock. >> >> XPath is only used for the creation of the partial lock. >> Conceptually, the scope of the lock is defined by the returned node >> set and not by the XPath expression. > > These paragraphs seem to dance around some point that's not clear. > What to you mean "conceptually ... not by the xpath"? Why doesn't the > XPath expression tell you want you're trying to lock? > --------n the > reply. This is mostly useless information and will be annoying to > generate with proper namespace mappings. What is the win in reporting > to the client the information the client just sent to you? We I don't agree with these statements. It is useful and it is handled by the same code that already generates the error-path XPath expressions with namespaces etc. It was asked for by other reviewers. The actual set of nodes locked by an XpAth is dependent on the content of the datastore. It is nice to immediately know what did you exactly locked. > >> Note that if some of the >> requested nodes exist only in one of the datastores, the lock is >> granted on different nodes in different datastores. > > Don't hide "Note"s in unrelated paragraphs. Remember that > most readers skim, reading the topic sentence and then skipping > the rest of the paragraph if they (a) assume they know what you > are going to say, or (b) thing this paragraph doesn't interest > them. Allow the same lines, there are placing when you can > consolidate all the text about an issue in one spot instead of > interlacing the text with other topics. OK separate paragraph. > >> Each select expression MUST return a node set, and at least one >> of the node sets for one of the specified datastores MUST be non- >> empty. > > Is this done to catch errors? I don't understand how this helps. An expression might return a boolean which is an error. If all selects return an empty nodeset, and we don't actually lock anything this is not success either. > >> If the device supports the :xpath capability, any valid XPath 1.0 >> expression can be used. If the device does not support the >> :xpath capability, the XPath expression MUST be limited to an >> Instance Identifier expression. An Instance Identifier is an >> absolute path expression in abbreviated syntax, where predicates >> are used only to specify values for nodes defined as keys to >> distinguish multiple instances. > > Is the term "Instance Identifier" local to this draft? If so, maybe > it's time to make a "Terminology" section. At a minimum, it needs a > more complete definition. OK make it a definition. Incidentally, a YANG instance-identifier is an "Instance Identifier" as defined in this document. > > Is it worthwhile to put XPath expressions into a distinct argument? > .vs. expressions, instead of making the client "OR" them > together. OR would return a boolean We believe it is more clear to use multiple smaller expressions then one big one. (We had the same argument for tang-types.) > >> If a node is locked by a session, only that same session is able to >> modify that node or any node in the subtree underneath it. > > When a NETCONF session holds a lock on a node, no other session or > non-NETCONF mechanism of the system can change that node or any node > in the hierarchy of nodes beneath it. OK > > Merge this with the related text above (where I said this point needs > to be more strongly made). Its needed here as well. > >> If a top level node of a locked subtree is deleted, any other session >> can recreate it, as it is no longer covered by the lock. If all top >> level nodes are deleted, the lock will still be present. However, >> its scope will become nil (i.e., the lock will not cover any nodes). > > s/ nil (i.e., the/empty (since/ OK > > "cover" and "scope" are fuzzy. Define them and how they relate. (But > I think with better wording you can avoid these terms). OK rephrase. > > Nodes are released from the lock when they are deleted, at which > point other clients or non-NETCONF mechanisms are able to recreate them. > >> A NETCONF server MUST be able to grant multiple simultaneous partial >> locks to a single NETCONF session. If the scope of the individual >> locks overlaps, nodes in the common area MUST be locked until all of >> the locks are released. > > Nodes locked under multiple overlapping locks remain locked until > all such locks are released. Less clear, it does not state that partial locks MAY overlap. > >> A partial lock operation MUST fail if: >> >> o Any NETCONF session (including the current session) owns the >> global lock on any target datastore. >> >> o Any part of the scope to be locked is already locked by another >> management session/protocol, including other NETCONF sessions >> using the or any other non-NETCONF management >> method. >> >> o The NETCONF server implements access control, and the locking user >> does not have sufficient rights to all parts of a datastore >> section to be locked. > > The NETCONF server's access control mechanism does not give the > locking user sufficient rights to any nodes to be locked. OK, but is this really better? > >> The exact handling of access rights is >> outside the scope of this document, but it is assumed that there >> is an access control system that MAY deny or allow the partial >> lock operation. >> >> > > Two blank lines? OK, remove one. > >> As with most locking systems, it is possible that two management >> sessions trying to lock different parts of the configuration could >> become dead-locked. To avoid this situation, clients SHOULD lock >> everything they need in one operation. If that operation fails, the >> client SHOULD back down, release any previously acquired locks, and >> retry the proced. > >> If all the select expressions return an empty node set, the > tag> is 'operation-failed', and the is 'no-matches'. > > Why is this app-tag have dashes but the other's don't? "no matches". OK will be corrected. All app-tags will have dashes. > >> If any select expression returns something other than a node set, the >> is 'invalid-value', the is 'XPath does >> not return a node set'. > > How can the expression return something other than a node set? Take the xpath expression 1=1 > >> If the :xpath capability is not supported and the XPath expression is >> not an Instance Identifier, the is 'invalid-value', the >> is ':xpath capability not supported'. > > Show some love to your users: "invalid lock specification" I love users, but ??????????????? > >> If access control denies the partial lock, the is >> 'access-denied'. > > "access denied". access-denied is used in RFC4741. We should not redefine it. > >> 2.4.1.2. Reserving model sections for future work > > This is a poor title. "Locking nodes before they are created"? OK will be changed to "Reserving nodes for future editing" "Locking nodes before they are created" is not good because that is exactly what is not possible. > >> Partial lock cannot be used to lock non-existent nodes, which would >> effectively attempt to reserve them for future use. To guarantee >> that a node cannot be created by some other session, the parent node >> SHOULD be locked, the top level node of the new section created, and >> then locked with another operation. After this, the >> lock on the parent node SHOULD be removed. > > Since partial locks cannot be taken out for nodes that do not exist, > special handling is required on the client to handle scenarios the > locking of newly created nodes. To guarantee ... No, I like this better. The content seems to be the same. > >> 2.4.2. >> >> The operation unlocks the parts of the datastores that were >> previously locked using during the same session. >> >> Parameters: >> >> lock-id: Lock identifier to unlock, taken from a reply to a previous >> operation. > > > This lock-id MUST have been received as a response to a lock request > by the NETCONF server during the current session, and MUST NOT have > been sent in a previous unlock request. OK > >> 2.5. Modifications to Existing Operations >> >> A successful partial lock will cause a subsequent operation to fail >> if it attempts to modify the locked area and is executed in a NETCONF >> session other than the session that owns the lock. > > Fail with what error? Same as in the case in global lock. It will be included. > > s/owns/has been granted/ OK > > "locked area" is a new term. Is it not understandable? OK, scope of the lock will be used. > >> All operations >> that modify the datastore are affected, including: , >> , , and . A >> successful partial lock will also cause the (global) operation >> to fail. All of these operations are affected only if they are >> targeting the same datastore. > > "successful" here is confusing. You make it sound like the > partial-lock operation will cause a to fail, rather > than the existence of locked nodes. OK, reword. > > ? You can't commit it someone else has a partial lock? > > I think you need to put more words into what operations are not > allowed. I know it sounds trivial to say it, but are things > like insert allowed? What words are missing. If insert modifies data it is not allowed. We can't give a full specification of all operations, as we will have more operations comming up e.g. YANG defined RPCs. > >> 2.6.2. Confirmed Commit Capability >> >> If: >> >> >> >> >> Lengyel & Bjorklund Expires May 2, 2009 [Page 9] >> >> Internet-Draft ure after waiting some time interval. The length of >> the interval SHOULD be random to avoid repeated dead-locks when both >> (or all) clients back down and then retry the partial lock operation. > > Need a "Deadlock Avoidance" section. No with don't want to make this into a tutorial. > > "back down" is a fuzzy concept. If you want want exponential back-off, say so. OK, reword. > > s/dead-lock/deadlock/ OK > >> The operation is designed for simplicity, so when a >> partial lock is executed you get what you asked for: a set of nodes >> that are locked for writing. There are some other issues that are >> intentionally not addressed: > > "not addressed"? Hogwash. Address them. Misunderstanding. We will rephrase. The issues ARE addressed in the following paragraphs. These paragraphs rather describe items that are out of scope. > >> o Locking does not affect read operations. > > Address it: Say "Locking does not affect read operations". It is stated. > >> o If part of a datastore is locked, this has no effect on any >> unlocked parts of the datastore. If this is a problem (e.g., >> changes depend on data values in the unlocked part of the >> datastore), these values SHOULD be included in the scope of the >> lock. > > s/values/nodes/ OK > > s/SHOULD/should/ since this is not a requirement of the specification. OK > > Address it: If the client should not attempting operations that rely > on configuration that is not locked. We don't want to state more, this is not a tutorial. > >> o Configuration data can be edited both inside and outside the scope >> of a lock. It is the responsibility of the NETCONF client >> application to lock all relevant parts of a datastore that are >> crucial for a specific management action. > > Address it. This is a big point and should be in a list of "things we > didn't address". > >> Note: The operation does not modify the global >> operation defined in the base NETCONF Protocol [NETCONF]. If part of >> a datastore is already locked by , then a global lock >> for that datastore MUST fail even if the global lock is requested by >> the NETCONF session that owns the partial lock. > > Make a section on "Interactions with and ", so this is > more visible to the reader (and in the table of contents). It would be unusual to have a separate section on all the things we do not modify. > >> 2.4.1.1. Parameters, Result, Examples >> >> Parameters: >> >> target: Name of one or more configuration datastores of which a part >> shall be locked. If multiple datastores are specified the same >> select parameter(s) are used for all of them. For each datastore >> locking of the same set of nodes will be requested. > > "same set of nodes": it won't be the same set of nodes if the > datastores have different contents. OK remove last sentence. > > I mentioned before that having one will multiple contents and > multiple ? No, because select usually selects a group of nodes, while identifiers must always point out one individual node. Will be described in the definition. > >> Positive Response: >> If the device was able to satisfy the request, an is sent >> with a element (lock identifier) in the >> element. A list of locked nodes per datastore is also returned in >> Instance Identifier format. > > So if I lock all sonet interfaces, I get a list of all sonet > interfaces? When do I need this? Because it might not be trivial for all XPath expressions which nodes are exactly in their scope. > >> Negative Response: >> If a lock is already held by another session on any node within the >> subtrees to be locked, the element is 'lock-denied' and >> the element includes the of the lock owner. >> If the lock is held by a non-NETCONF session, a of 0 >> (zero) is included. If needed the returned session-id may be used to >> the NETCONF session holding the lock. The same error >> response is returned if the requesting session already holds the >> (global) lock for the same datastore. > > If global locks are the same, merge their handling into the text. They are not the same. multiple partial locks for the same session are OK, but you can not have a partial and a global lock side by side. > > If a partial lock is already held by another session on any node > within the subtrees to be locked or a global lock is held by any > NETCONF client, the element is 'lock-denied' and... > >> If all the select expressions return an empty node set, the > tag> is 'operation-failed', and the is 'no-matches'. > > Why is this app-tag have dashes but the other's don't? "no matches". OK will be corrected. All app-tags will have dashes. > >> If any select expression returns something other than a node set, the >> is 'invalid-value', the is 'XPath does >> not return a node set'. > > How can the expression return something other than a node set? Take the xpath expression 1=1 > >> If the :xpath capability is not supported and the XPath expression is >> not an Instance Identifier, the is 'invalid-value', the >> is ':xpath capability not supported'. > > Show some love to your users: "invalid lock specification" I love users, but ??????????????? > >> If access control denies the partial lock, the is >> 'access-denied'. > > "access denied". access-denied is used in RFC4741. We should not redefine it. > >> 2.4.1.2. Reserving model sections for future work > > This is a poor title. "Locking nodes before they are created"? OK will be changed to "Reserving nodes for future editing" "Locking nodes before they are created" is not good because that is exactly what is not possible. > >> Partial lock cannot be used to lock non-existent nodes, which would >> effectively attempt to reserve them for future use. To guarantee >> that a node cannot be created by some other session, the parent node >> SHOULD be locked, the top level node of the new section created, and >> then locked with another operation. After this, the >> lock on the parent node SHOULD be removed. > > Since partial locks cannot be taken out for nodes that do not exist, > special handling is required on the client to handle scenarios the > locking of newly created nodes. To guarantee ... No, I like this better. The content seems to be the same. > >> 2.4.2. >> >> The operation unlocks the parts of the datastores that were >> previously locked using during the same session. >> >> Parameters: >> >> lock-id: Lock identifier to unlock, taken from a reply to a previous >> operation. > > > This lock-id MUST have been received as a response to a lock request > by the NETCONF server during the current session, and MUST NOT have > been sent in a previous unlock request. OK > >> 2.5. Modifications to Existing Operations >> >> A successful partial lock will cause a subsequent operation to fail >> if it attempts to modify the locked area and is executed in a NETCONF >> session other than the session that owns the lock. > > Fail with what error? Same as in the case in global lock. It will be included. > > s/owns/has been granted/ OK > > "locked area" is a new term. Is it not understandable? OK, scope of the lock will be used. > >> All operations >> that modify the datastore are affected, including: , >> , , and . A >> successful partial lock will also cause the (global) operation >> to fail. All of these operations are affected only if they are >> targeting the same datastore. > > "successful" here is confusing. You make it sound like the > partial-lock operation will cause a to fail, rather > than the existence of locked nodes. OK, reword. > > ? You can't commit it someone else has a partial lock? > > I think you need to put more words into what operations are not > allowed. I know it sounds trivial to say it, but are things > like insert allowed? What words are missing. If insert modifies data it is not allowed. We can't give a full specification of all operations, as we will have more operations comming up e.g. YANG defined RPCs. > >> 2.6.2. Confirmed Commit Capability >> >> If: >> >> >> >> >> Lengyel & Bjorklund Expires May 2, 2009 [Page 9] >> >> Internet-Draft Partial Lock RPC for NETCONF October 2008 > > This "If:" is a _horrible_ case of hanging text. I think this can be > avoided completely if you rephrase the text a bit: > > If the NETCONF server supports the :confirmed-commit capability and a > confirmed commit is outstanding, partial lock requests for the > database MUST be denied, since the running datastore must be > rolled back if a confirming commit is not performed within the > appropriate time window. It might not be the best but it is very clear. A native English speaker has composed these sentences. > >> In this case the 'in-use' and the 'Lock >> denied, Outstanding confirmed commit' is returned. > > Can we please use lower case for app-tag values? OK > >> 2.6.3. Distinct Startup Capability >> Partial locking of the startup datastore can only be done if the >> :startup capability is supported by the device. > > :startup is not a valid target for , so it should not be > a target for partial locks. Copy-config is valid for startup so locking is needed. If I am only interested in locking part of the datastore using partial lock is enough, no need for a global lock. (It is not really stated in 4741 that startup can not be the target of edit-config.) > >> 3. Security Considerations >> ... >> Partial locking is NOT an authorization mechanism; it SHOULD NOT be >> used to provide security or access control. Partial locking SHOULD >> only be used as a mechanism for providing consistency when multiple >> managers are trying to configure the node. It is vital that users >> easily understand the exact scope of a lock. This is why the scope >> is determined when granting a lock and is not modified thereafter. > > "users"? Users understand XPaths expressions? "exact scope"? I > don't get this argument. The way you've got this working, not one > can understand the exact scope of a lock. If I lock all sonet > interfaces, no one without a log file and a crystal ball will be able > to tell me which sonet interfaces I have locked. Any interfaces > created after I got my lock aren't locked. Anything I deleted and > someone (even me) recreated isn't locked. If you are looking for > exactness and understandability, you need to rethink this. > The scope of the lock is exactly specified as a list of nodes in the rpc-reply. If we would use the xpath as the definition instead of the list of nodes, the scope could change due to unrelated edit operations. >> 5. Appendix A - XML Schema for Partial Locking (normative) > > For the record, I didn't read this section. > >> 6. Appendix B - YANG Module for Partial Locking (non-normative) >> module netconf-partial-lock { > > s/netconf/ietf-netconf/ Ask work group !!! > > IETF YANG modules should all start with "ietf-". > >> grouping configNames { > > Should this be an identify? I don't see the need for it. It is not handled as identity in other Netconf RFCs. It would be inconsistent to use identities here. Identities don't yet exist, as yang is not complete. I was told that as yet the XSD must be the normative, where identities are not primary constructs. > >> container target { >> description >> "A list of one or more datastore names."; >> leaf running { type empty; } >> leaf candidate { type empty; } >> leaf startup { type empty; } > > Add if-features for :writable-running, :candidate, and :startup. I don't see the need to have features to duplicate the information already contained in capabilities. > >> leaf-list select { >> description >> "XPath expression that specifies the scope of the lock. >> An Instance Identifier expression MUST be used unless the >> :xpath capability is supported, in which case any XPath 1.0 >> expression is allowed."; >> type string; > > We should have a typedef for XPath expressions (locationPath). I would rather leave that to yang-types. Might be a good idea. > >> output { >> leaf lock-id { >> description >> "Identifies the lock, if granted. The lock-id MUST be >> used in the partial-unlock rpc."; > > MUST? I can do my change and then terminate my connection without > doing a partial-unlock. OK reword. > >> type uint32; > > This should be a typedef. OK. > > ------------------- > _______________________________________________ > 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 Mon Nov 17 20:25: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 510423A6A85; Mon, 17 Nov 2008 20:25:44 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FDE13A6A85 for ; Mon, 17 Nov 2008 20:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ASr83y3BCEg for ; Mon, 17 Nov 2008 20:25:41 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 760613A6827 for ; Mon, 17 Nov 2008 20:25:40 -0800 (PST) Received: from source ([66.129.228.6]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSSJDtAHJ61MEBrEVnYmXhekbqFYCrHsN@postini.com; Mon, 17 Nov 2008 20:25:40 PST Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 20:25:02 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 20:25:02 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 20:25:01 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mAI4P0M89898; Mon, 17 Nov 2008 20:25:00 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id mAI4K1wG046338; Tue, 18 Nov 2008 04:20:01 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200811180420.mAI4K1wG046338@idle.juniper.net> To: balazs.lengyel@ericsson.com In-reply-to: <4921D383.2080102@ericsson.com> Date: Mon, 17 Nov 2008 23:20:01 -0500 From: Phil Shafer X-OriginalArrivalTime: 18 Nov 2008 04:25:01.0830 (UTC) FILETIME=[9FB4F260:01C94935] Cc: netconf@ietf.org Subject: Re: [Netconf] partial-lock feedback X-BeenThere: netconf@ietf.org X-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: >> You call out state data; should you also call out notification and >> rpc data? > >What is the meaning of locking rpc or a notification? It does not exist for a >prolonged >time, so what does it mean that it doesn't changed. I don't think this is need >ed. What is the meaning of locking state data? Why call it out specifically without calling out the other odd data contexts that are not lockable? Perhaps you should just state "Only configuration data can be locked". >> In NETCONF, the locks are short duration, meant to allow the client to >> grab it, change the config, and release it. Are partial lock similar? >> Do you need to say something about the operating model for partial >> locks? > >No we want to minimize describing intenFrom netconf-bounces@ietf.org Mon Nov 17 20:25: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 510423A6A85; Mon, 17 Nov 2008 20:25:44 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FDE13A6A85 for ; Mon, 17 Nov 2008 20:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ASr83y3BCEg for ; Mon, 17 Nov 2008 20:25:41 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 760613A6827 for ; Mon, 17 Nov 2008 20:25:40 -0800 (PST) Received: from source ([66.129.228.6]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSSJDtAHJ61MEBrEVnYmXhekbqFYCrHsN@postini.com; Mon, 17 Nov 2008 20:25:40 PST Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 20:25:02 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 20:25:02 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 20:25:01 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mAI4P0M89898; Mon, 17 Nov 2008 20:25:00 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id mAI4K1wG046338; Tue, 18 Nov 2008 04:20:01 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200811180420.mAI4K1wG046338@idle.juniper.net> To: balazs.lengyel@ericsson.com In-reply-to: <4921D383.2080102@ericsson.com> Date: Mon, 17 Nov 2008 23:20:01 -0500 From: Phil Shafer X-OriginalArrivalTime: 18 Nov 2008 04:25:01.0830 (UTC) FILETIME=[9FB4F260:01C94935] Cc: netconf@ietf.org Subject: Re: [Netconf] partial-lock feedback X-BeenThere: netconf@ietf.org X-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: >> You call out state data; should you also call out notification and >> rpc data? > >What is the meaning of locking rpc or a notification? It does not exist for a >prolonged >time, so what does it mean that it doesn't changed. I don't think this is need >ed. What is the meaning of locking state data? Why call it out specifically without calling out the other odd data contexts that are not lockable? Perhaps you should just state "Only configuration data can be locked". >> In NETCONF, the locks are short duration, meant to allow the client to >> grab it, change the config, and release it. Are partial lock similar? >> Do you need to say something about the operating model for partial >> locks? > >No we want to minimize describingded usage. Can you explain this? Minimizing describing intended usage doesn't sound like something that will help create interoperable implementations. >RC4741 does not allow extending the lock requirement (We might be argument abo >ut this, but >this is the current situation.). We can certainly debate whether that is the current situation. >>> Each XPath >>> expression MUST return a node set. >> >> This is an odd sentence. What are you trying to say? Are you worried >> that someone will think you mean predicate expressions? Do you want >> to explicit reference the XPath spec'c production name (LocationPath >> in section 2.0 of http://www.w3.org/TR/xpath.html). > >An XPath expression can return a node set, a boolean, a >number or a string (see section 1. in http://www.w3.org/TR/xpath). True, which is why I'm suggesting you choose a more specific production name, such as LocationPath or UnionExpr (see section 3.3 of xpath). >> Locking multiple datastores requires maximally pessimistic lock use, >> right? I MUST lock it everywhere to protect myself. Seems >> pointless. There's some logic that says the intersection of >> boxes with :writable-running and :candidate is (or should be) nil. >> So you should only need to lock one or the other. > >It is not stated anywhere that you can't have candidate and writable-running t >ogether. So >give pessimists some tools. Tools yes, but very expensive ones. >>> If the configuration data is later altered in a way that would make >>> the original select XPath expressions evaluate to a different set of >>> nodes, this does not affect the scope of the partial lock. >>> >>> XPath is only used for the creation of the partial lock. >>> Conceptually, the scope of the lock is defined by the returned node >>> set and not by the XPath expression. >> >> These paragraphs seem to dance around some point that's not clear. >> What to you mean "conceptually ... not by the xpath"? Why doesn't the >> XPath expression tell you want you're trying to lock? >> >------------------------------------------------------------------------------ >-------------------------------------- ???? >> This last sentence is unclear (or evil). "previously locked during" >> includes anything I had locked from previous lock requests, which >> isn't what you want. > >Misunderstanding. It is stated that: >unlock all parts that were previously LOCKED DURING THAT OPERATION. This indic >ates that >only nodes locked during that same operation are involved. That's the part that's unclear. "previously" and "during" are in conflict. "previously locked" can't apply to node while the lock operation is going on, since those nodes aren't locked until the (atomic) lock operation completes. >> This whole issue makes me wonder why you need to support multiple >> a is identical to: >> Nodes are released from the lock when they are deleted, at which >> point other clients or non-NETCONF mechanisms are able to recreate them. >> >>> A NETCONF server MUST be able to grant multiple simultaneous partial >>> locks to a single NETCONF session. If the scope of the individual >>> locks overlaps, nodes in the common area MUST be locked until all of >>> the locks are released. >> >> Nodes locked under multiple overlapping locks remain locked until >> all such locks are released. > >Less clear, it does not state that partial locks MAY overlap. Keep the first sentence. Repair the second one. >>> A partial lock operation MUST fail if: >>> >>> o Any NETCONF session (including the current session) owns the >>> global lock on any target datastore. >>> >>> o Any part of the scope intended usage. Can you explain this? Minimizing describing intended usage doesn't sound like something that will help create interoperable implementations. >RC4741 does not allow extending the lock requirement (We might be argument abo >ut this, but >this is the current situation.). We can certainly debate whether that is the current situation. >>> Each XPath >>> expression MUST return a node set. >> >> This is an odd sentence. What are you trying to say? Are you worried >> that someone will think you mean predicate expressions? Do you want >> to explicit reference the XPath spec'c production name (LocationPath >> in section 2.0 of http://www.w3.org/TR/xpath.html). > >An XPath expression can return a node set, a boolean, a >number or a string (see section 1. in http://www.w3.org/TR/xpath). True, which is why I'm suggesting you choose a more specific production name, such as LocationPath or UnionExpr (see section 3.3 of xpath). >> Locking multiple datastores requires maximally pessimistic lock use, >> right? I MUST lock it everywhere to protect myself. Seems >> pointless. There's some logic that says the intersection of >> boxes with :writable-running and :candidate is (or should be) nil. >> So you should only need to lock one or the other. > >It is not stated anywhere that you can't have candidate and writable-running t >ogether. So >give pessimists some tools. Tools yes, but very expensive ones. >>> If the configuration data is later altered in a way that would make >>> the original select XPath expressions evaluate to a different set of >>> nodes, this does not affect the scope of the partial lock. >>> >>> XPath is only used for the creation of the partial lock. >>> Conceptually, the scope of the lock is defined by the returned node >>> set and not by the XPath expression. >> >> These paragraphs seem to dance around some point that's not clear. >> What to you mean "conceptually ... not by the xpath"? Why doesn't the >> XPath expression tell you want you're trying to lock? >> >------------------------------------------------------------------------------ >-------------------------------------- ???? >> This last sentence is unclear (or evil). "previously locked during" >> includes anything I had locked from previous lock requests, which >> isn't what you want. > >Misunderstanding. It is stated that: >unlock all parts that were previously LOCKED DURING THAT OPERATION. This indic >ates that >only nodes locked during that same operation are involved. That's the part that's unclear. "previously" and "during" are in conflict. "previously locked" can't apply to node while the lock operation is going on, since those nodes aren't locked until the (atomic) lock operation completes. >> This whole issue makes me wonder why you need to support multiple >> a is identical to: >> Nodes are released from the lock when they are deleted, at which >> point other clients or non-NETCONF mechanisms are able to recreate them. >> >>> A NETCONF server MUST be able to grant multiple simultaneous partial >>> locks to a single NETCONF session. If the scope of the individual >>> locks overlaps, nodes in the common area MUST be locked until all of >>> the locks are released. >> >> Nodes locked under multiple overlapping locks remain locked until >> all such locks are released. > >Less clear, it does not state that partial locks MAY overlap. Keep the first sentence. Repair the second one. >>> A partial lock operation MUST fail if: >>> >>> o Any NETCONF session (including the current session) owns the >>> global lock on any target datastore. >>> >>> o Any part of the to be locked is already locked by another >>> management session/protocol, including other NETCONF sessions >>> using the or any other non-NETCONF management >>> method. >>> >>> o The NETCONF server implements access control, and the locking user >>> does not have sufficient rights to all parts of a datastore >>> section to be locked. >> >> The NETCONF server's access control mechanism does not give the >> locking user sufficient rights to any nodes to be locked. > >OK, but is this really better? Dismisses the unrealistic case of the server not implementing access control. >> Need a "Deadlock Avoidance" section. >No with don't want to make this into a tutorial. You don't need a tutorial, but having "deadlock" show up in the table of contents of an RFC on locking seems appropriate. Covering it in a section on New Operations isn't. >Misunderstanding. We will rephrase. The issues ARE addressed in the following >paragraphs. >These paragraphs rather describe items that are out of scope. Please rephrase this, since it's very confusing. Even your "items that are out of scope" comment here seems to say that you are not addressing these points. >> Address it: If the client should not attempting operations that rely >> on configuration that is not locked. >We don't want to state more, this is not a tutorial. I don't think this turns your draft into a tutorial. >> Make a section on "Interactions with and ", so this is >> more visible to the reader (and in the table of contents). > >It would be unusual to have a separate section on all the things we do not mod >ify. But you _did_ change it. Global locks do not operate the same way. If some party has a partial lock, requests for the global lock will fail. >> I mentioned before that having one will multiple contents and >> multiple s is inconsistent. You also need to think about what >> it would look like if we make an identity called "datastore" in >> 4741-bis and folks extend it with or or . >> When they want to lock multiple files, how will it work? >> > >Take it to workgroup meeting. I don't think we want to go into (or worry about >) file >locking. We will cross that bridge, when we get there. I'm clearly not saying you need to cross that bridge, just that you should spend some time thinking about future evolution of netconf. >> Make one paragraph on locked and a different one on reporting. Mixing >> different topics in one paragraph is hard for the reader (and worse >> for the skimmer). > >I think the current text is OK OK, but not good. In technical writing, you want the topic sentence to contain a paragraph's main idea. The rest of the paragraph should support and develop that idea with related details. If the reader sees a topic sentence of "The nodes that matched the select expression and are locked are reported in the rpc-reply message.", they will expect the rest of the paragraph to be related, but "Note that if some of the requested nodes exist only in one of the datastores, the lock is granted on different nodes in different datastores." isn't related. >> I strongly dislike the idea of reporting what was locked in the >> reply. This is mostly useless information and will be annoying to >> generate with proper namespace mappings. What is the win in reporting >> to the client the information the client just sent to you? > >We I don't agree with these statements. It is useful and it is handled >by the same code that already generates the error-path XPath >expressions with namespaces etc. It was asked for by other reviewers. >The actual set of nodes locked by an XpAth is >dependent on the content of the datastore. It is nice to immediately >know what did you exactly locked. "nice" depends on the database. If you lock 90,000 things, having someone tell you is definitely not nice. Even if you lock one or two things, you know what you locked and don't need someone to tell you. >> Is it worthwhile to put XPath expressions into a distinct nt? >> .vs. ? > >No, because select usually selects a group of nodes, while identifiers must al >ways point >out one individual node. Will be described in the definition. This is more to my point. The XPath select and the non-XPath instance identifier are different datatypes. In YANG, one would be w3c:UnionExpr and the other yang:instance-identifier (or something like that). Where's the win of putting them in the same argument? >>> Positive Response: >>> If the device was able to satisfy the request, an is sent >>> with a element (lock identifier) in the >>> element. A list of locked nodes per datastore is also returned in >>> Instance Identifier format. >> >> So if I lock all sonet interfaces, I get a list of all sonet >> interfaces? When do I need this? > >Because it might not be trivial for all XPath expressions which nodes are exac >tly in their >scope. If you wanted this, could you add another RPC, like rpc get-partial-lock-information { input { leaf lockId { ... } } output { container partial-lock-information { list lockedNode { ... } } } } Don't put the price of this not-so-nice behavior on every locker. >>> If the :xpath capability is not supported and the XPath expression is >>> not an Instance Identifier, the is 'invalid-value', the >>> is ':xpath capability not supported'. >> >> Show some love to your users: "invalid lock specification" > >I love users, but ??????????????? Sorry, I didn't make my point clearly. I make the assumption that error messages will most likely be displayed directly to the users of applications. Choosing text that will be lucid to non-developers reduces the shock to the user. >>> Partial lock cannot be used to lock non-existent nodes, which would >>> effectively attempt to reserve them for future use. To guarantee >>> that a node cannot be created by some other session, the parent node >>> SHOULD be locked, the top level node of the new section created, and >>> then locked with another operation. After this, the >>> lock on the parent node SHOULD be removed. >> >> Since partial locks cannot be taken out for nodes that do not exist, >> special handling is required on the client to handle scenarios the >> locking of newly created nodes. To guarantee ... > >No, I like this better. The content seems to be the same. I find "reserve them for future use" confusing. I was trying to suggest an alternative, but anything that avoids this phrase would be better. >> If the NETCONF server supports the :confirmed-commit capability and a >> confirmed commit is outstanding, partial lock requests for the >> database MUST be denied, since the running datastore must be >> rolled back if a confirming commit is not performed within the >> appropriate time window. > >It might not be the best but it is very clear. A native English speaker has co >mposed these >sentences. I do not think this is an English issue but one of text organization. Bulleting here isn't necessary. >Copy-config is valid for startup so locking is needed. If I am only interested > in locking >part of the datastore using partial lock is enough, no need for a global lock. But the startup datastore isn't required to be parsable/addressable. It's a blob with no internal visibility. It's data in a SRAM, not something you can run XPaths expression on. >(It is not really stated in 4741 that startup can not be the target of edit-co >nfig.) 8.7.5.1 lists the set of operations for which is an allowed target. is not among them. This choice was intentional, since startup config is not required to be in memory, addressable, parsed, open, searchable, or available for XPath expressions. It's typically a section of SRAM or flash; you can read it or write it, but that's about it. >>> module netconf-partial-lock { >> s/netconf/ietf-netcosk work group !!! Isn't that what review comments do? Do I need to open formal issues for items that need to be addressed? Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf nf/ >Ask work group !!! Isn't that what review comments do? Do I need to open formal issues for items that need to be addressed? Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Nov 18 13:32: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 9F25F28C267; Tue, 18 Nov 2008 13:32:59 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6991628C268 for ; Tue, 18 Nov 2008 13:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lx9O1DPFr-wU for ; Tue, 18 Nov 2008 13:32:57 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4D75E28C259 for ; Tue, 18 Nov 2008 13:32:57 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAILWppv001640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Nov 2008 22:32:52 +0100 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 mAILWnJr029194; Tue, 18 Nov 2008 22:32:51 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 22:32:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 22:16:23 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Short Summary of the NETCONF WG session on MONDAY, Nov 17 2008 Thread-Index: AclJwujzYx8XaEFoRFinIsHMJZdFpA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Romascanu, Dan (Dan)" X-OriginalArrivalTime: 18 Nov 2008 21:32:50.0749 (UTC) FILETIME=[353F36D0:01C949C5] Cc: netconf@ietf.org Subject: [Netconf] Short Summary of the NETCONF WG session on MONDAY, Nov 17 2008 X-BeenThere: netconf@ietf.org X-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 Dan, please find below a short summary of the NETCONF WG session on MONDAY, Nov 17 2008 1740-1930: - We had 45 persons in the 2 hour NETCONF session. - We reviewed the status of the WG - We went through the chartered WG items and had a good discussion and review of the documents. - NETCONF over TLS is in AD evaluation after WGLC. - Partial Lock RPC had a WGLC. An update is necessary for editorial fixes and clarifications. - NETCONF Monitoring Schema draft had some discussion on the necessary data types. A proposal will be posted to the maillist after consolidation with key players for this topic. - Martin Bjorklund and Juergen Schoenwaelder are going to prepare the 4741bis draft focusing on bug fixes and necessary clarifications. It is not going to become a V2.0. - The WG sees the With-defaults capability draft as important and it will be prepared as a separaFrom netconf-bounces@ietf.org Tue Nov 18 13:32: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 9F25F28C267; Tue, 18 Nov 2008 13:32:59 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6991628C268 for ; Tue, 18 Nov 2008 13:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lx9O1DPFr-wU for ; Tue, 18 Nov 2008 13:32:57 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4D75E28C259 for ; Tue, 18 Nov 2008 13:32:57 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAILWppv001640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Nov 2008 22:32:52 +0100 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 mAILWnJr029194; Tue, 18 Nov 2008 22:32:51 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 22:32:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 22:16:23 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Short Summary of the NETCONF WG session on MONDAY, Nov 17 2008 Thread-Index: AclJwujzYx8XaEFoRFinIsHMJZdFpA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Romascanu, Dan (Dan)" X-OriginalArrivalTime: 18 Nov 2008 21:32:50.0749 (UTC) FILETIME=[353F36D0:01C949C5] Cc: netconf@ietf.org Subject: [Netconf] Short Summary of the NETCONF WG session on MONDAY, Nov 17 2008 X-BeenThere: netconf@ietf.org X-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 Dan, please find below a short summary of the NETCONF WG session on MONDAY, Nov 17 2008 1740-1930: - We had 45 persons in the 2 hour NETCONF session. - We reviewed the status of the WG - We went through the chartered WG items and had a good discussion and review of the documents. - NETCONF over TLS is in AD evaluation after WGLC. - Partial Lock RPC had a WGLC. An update is necessary for editorial fixes and clarifications. - NETCONF Monitoring Schema draft had some discussion on the necessary data types. A proposal will be posted to the maillist after consolidation with key players for this topic. - Martin Bjorklund and Juergen Schoenwaelder are going to prepare the 4741bis draft focusing on bug fixes and necessary clarifications. It is not going to become a V2.0. - The WG sees the With-defaults capability draft as important and it will be prepared as a separate drate draft. - After a long discussion the WG decided to prepare the Notification content draft with a fast process. The WG will start with a new draft which will contain only 1-2 explicitely necessary notification content. The co-chairs will ask the WG for volunteering authors. - We are going to ask you soon for the approval of an updated charter covering the new work for 4741bis, Withdefault capability and Notification content. Cheers, Bert & Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ft. - After a long discussion the WG decided to prepare the Notification content draft with a fast process. The WG will start with a new draft which will contain only 1-2 explicitely necessary notification content. The co-chairs will ask the WG for volunteering authors. - We are going to ask you soon for the approval of an updated charter covering the new work for 4741bis, Withdefault capability and Notification content. Cheers, Bert & Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Nov 18 13:34: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 341273A68C4; Tue, 18 Nov 2008 13:34:04 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D198F3A68C4 for ; Tue, 18 Nov 2008 13:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 HeAGtMp0hAmh for ; Tue, 18 Nov 2008 13:34:03 -0800 (PST) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id BD7CE3A6885 for ; Tue, 18 Nov 2008 13:34:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,627,1220241600"; d="scan'208";a="142558112" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 18 Nov 2008 16:34:01 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Nov 2008 16:34:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 22:33:58 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Short Summary of the NETCONF WG session on MONDAY, Nov 17 2008 Thread-Index: AclJwujzYx8XaEFoRFinIsHMJZdFpAAAmyQw References: From: "Romascanu, Dan (Dan)" To: "Ersue, Mehmet (NSN - DE/Munich)" Cc: netconf@ietf.org Subject: Re: [Netconf] Short Summary of the NETCONF WG session on MONDAY, Nov 17 2008 X-BeenThere: netconf@ietf.org X-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 Thanks. Dan > -----Original Message----- > From: Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com] > Sent: Tuesday, November 18, 2008 11:16 PM > To: Romascanu, Dan (Dan) > Cc: Bert Wijnen (IETF); netconf@ietf.org > Subject: Short Summary of the NETCONF WG session on MONDAY, > Nov 17 2008 > > > Hi Dan, > > please find below a short summary of the NETCONF WG session > on MONDAY, Nov 17 2008 1740-1930: > > - We had 45 persons in the 2 hour NETCONF session. > - We reviewed the status of the WG > - We went through the chartered WG items and had a > good discussion and review of the documents. > > - NETCONF over TLS is in AD evaluation after WGLC. > - Partial Lock RPC had a WGLC. An update is necessary > for editorial fixes and clarifications. > - NETCONF Monitoring Schema draft had some discussion > on the necessary data types. A proposal will be posted > to the maillist after consolidation with key players for > this topic. > > - Martin Bjorklund and Juergen Schoenwaelder are going > to prepare the 4741bis draft focusing on bug fixes and > necessary clarifications. It is not going to become a V2.0. > - The WG sees the With-defaults capability draft as important > and it will be prepared as a separate draft. > - After a long discussion the WG decided to prepare the > Notification content draft with a fast process. The WG > will start with a new draft which will contain only 1-2 > explicitely necessary notification content. The co-chairs > will ask the WG for volunteering authors. > - We are going to ask you soon for the approval of an > updated charter covering the new work for 4741bis, > Withdefault capability and Notification content. > > Cheers, > Bert & Mehmet > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Nov 18 13:34: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 341273A68C4; Tue, 18 Nov 2008 13:34:04 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D198F3A68C4 for ; Tue, 18 Nov 2008 13:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 HeAGtMp0hAmh for ; Tue, 18 Nov 2008 13:34:03 -0800 (PST) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id BD7CE3A6885 for ; Tue, 18 Nov 2008 13:34:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,627,1220241600"; d="scan'208";a="142558112" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 18 Nov 2008 16:34:01 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Nov 2008 16:34:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 22:33:58 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Short Summary of the NETCONF WG session on MONDAY, Nov 17 2008 Thread-Index: AclJwujzYx8XaEFoRFinIsHMJZdFpAAAmyQw References: From: "Romascanu, Dan (Dan)" To: "Ersue, Mehmet (NSN - DE/Munich)" Cc: netconf@ietf.org Subject: Re: [Netconf] Short Summary of the NETCONF WG session on MONDAY, Nov 17 2008 X-BeenThere: netconf@ietf.org X-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 Thanks. Dan > -----Original Message----- > From: Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com] > Sent: Tuesday, November 18, 2008 11:16 PM > To: Romascanu, Dan (Dan) > Cc: Bert Wijnen (IETF); netconf@ietf.org > Subject: Short Summary of the NETCONF WG session on MONDAY, > Nov 17 2008 > > > Hi Dan, > > please find below a short summary of the NETCONF WG session > on MONDAY, Nov 17 2008 1740-1930: > > - We had 45 persons in the 2 hour NETCONF session. > - We reviewed the status of the WG > - We went through the chartered WG items and had a > good discussion and review of the documents. > > - NETCONF over TLS is in AD evaluation after WGLC. > - Partial Lock RPC had a WGLC. An update is necessary > for editorial fixes and clarifications. > - NETCONF Monitoring Schema draft had some discussion > on the necessary data types. A proposal will be posted > to the maillist after consolidation with key players for > this topic. > > - Martin Bjorklund and Juergen Schoenwaelder are going > to prepare the 4741bis draft focusing on bug fixes and > necessary clarifications. It is not going to become a V2.0. > - The WG sees the With-defaults capability draft as important > and it will be prepared as a separate draft. > - After a long discussion the WG decided to prepare the > Notification content draft with a fast process. The WG > will start with a new draft which will contain only 1-2 > explicitely necessary notification content. The co-chairs > will ask the WG for volunteering authors. > - We are going to ask you soon for the approval of an > updated charter covering the new work for 4741bis, > Withdefault capability and Notification content. > > Cheers, > Bert & Mehmet > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Nov 20 12:29: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 4F7453A698B; Thu, 20 Nov 2008 12:29:35 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82B243A698B for ; Thu, 20 Nov 2008 12:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vY4qCEXScL7e for ; Thu, 20 Nov 2008 12:29:31 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 488353A677D for ; Thu, 20 Nov 2008 12:29:31 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E274C212C3; Thu, 20 Nov 2008 21:29:28 +0100 (CET) X-AuditID: c1b4fb3e-adf84bb00000537b-cb-4925c8a83249 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B73C1211DC; Thu, 20 Nov 2008 21:29:28 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 21:29:28 +0100 Received: from [127.0.0.1] ([159.107.197.237]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 21:29:27 +0100 Message-ID: <4925C8B6.5090100@ericsson.com> Date: Thu, 20 Nov 2008 21:29:42 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer References: <200811180420.mAI4K1wG046338@idle.juniper.net> In-Reply-To: <200811180420.mAI4K1wG046338@idle.juniper.net> X-OriginalArrivalTime: 20 Nov 2008 20:29:28.0252 (UTC) FILETIME=[AF9BB7C0:01C94B4E] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] partial-lock feedback X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: balazs.lengyel@ericsson.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Phil, Some further answers. See below! Balazs Phil Shafer wrote: > Balazs Lengyel writes: >>> You call out state data; should you also call out notification and >>> rpc data? >> What is the meaning of locking rpc or a notification? It does not exist for a >> prolonged >> time, so what does it mean that it doesn't changed. I don't think this is need >> ed. > > What is the meaning of locking state data? Why call it out > specifically without calling out the other odd data contexts > that are not lockable? Perhaps you should just state "Only > configuration data can be locked". OK. > >>> In NETCONF, the locks are short duration, meant to allow the client to >>> grab it, change the config, and release it. Are partial lock similar? >>> Do you need to say something about the operating model for partial >>> locks? >> No we want to minimize describing intended usage. > > Can you explain this? Minimizing describing intended usage > doesn't sound like something that will help create interoperable > implementations. OK, will try to add usage scenarios. --------------------------------------------------------------------------- > >> RC4741 does not allow extending the lock requirement (We might be argument abo >> ut this, but >> this is the current situation.). > > We can certainly debate whether that is the current situation. > >>>> Each XPath >>>> expression MUST return a node set. >>> This is an odd sentence. What are you trying to say? Are you worried >>> that someone will think you mean predicate expressions? Do you want >>> to explicit reference the XPath spec'c production name (LocationPath >>> in section 2.0 of http://www.w3.org/TR/xpath.html). >> An XPath expression can return a node set, a boolean, a >> number or a string (see section 1. in http://www.w3.org/TR/xpath). > > True, which is why I'm suggesting you choose a more specific production > name, such as LocationPath or UnionExpr (see section 3.3 of xpath). > >>> Locking multiple datastores requires maximally pessimistic lock use, >>> right? I MUST lock it everywhere to protect myself. Seems >>> pointless. There's some logic that says the intersection of >>> boxes with :writable-running and :candidate is (or should be) nil. >>> So you should only need to lock one or the other. >> It is not stated anywhere that you can't have candidate and writable-running t >> ogether. So >> give pessimists some tools. > > Tools yes, but very expensive ones. > >>>> If the configuration data is later altered in a way that would make >>>> the original select XPath expressions evaluate to a different set of >>>> nodes, this does not affect the scope of the partial lock. >>>> >>>> XPath is only used for the creation of the partial lock. >>>> Conceptually, the scope of the lock is defined by the returned node >>>> set and not by the XPath expression. >>> These paragraphs seem to dance around some point that's not clear. >>> What to you mean "conceptually ... not by the xpath"? Why doesn't the >>> XPath expression tell you want you're trying to lock? >>> >> ------------------------------------------------------------------------------ >> -------------------------------------- > > ???? OK, merged the two related paragraphs and added an example. > >>> This last sentence is unclear (or evil). "previously locked during" >>> includes anything I had locked from previous lock requests, which >>> isn't what you want. >> Misunderstanding. It is stated that: >> unlock all parts that were previously LOCKED DURING THAT OPERATION. This indic >> ates that >> only nodes locked during that same operation are involved. > > That's the part that's unclear. "previously" and "during" are in > conflict. "previously locked" can't apply to node while the lock > operation is going on, since those nodes aren't locked until the > (atomic) lock operation completes. > OK, reworded >>> This whole issue makes me wonder why you need to support multiple >>> a > > > is identical to: > > > Yes, but it is often easier to break potentially long expressions into multiple smaller ones. However the user can still use the union if he prefers to. >>> Nodes are released from the lock when they are deleted, at which >>> point other clients or non-NETCONF mechanisms are able to recreate them. >>> >>>> A NETCONF server MUST be able to grant multiple simultaneous partial >>>> locks to a single NETCONF session. If the scope of the individual >>>> locks overlaps, nodes in the common area MUST be locked until all of >>>> the locks are released. >>> Nodes locked under multiple overlapping locks remain locked until >>> all such locks are released. >> Less clear, it does not state that partial locks MAY overlap. > > Keep the first sentence. Repair the second one. Reworded paragraph. > >>>> A partial lock operation MUST fail if: >>>> >>>> o Any NETCONF session (including the current session) owns the >>>> global lock on any target datastore. >>>> >>>> o Any part of the scope to be locked is already locked by another >>>> management session/protocol, including other NETCONF sessions >>>> using the or any other non-NETCONF management >>>> method. >>>> >>>> o The NETCONF server implements access control, and the locking user >>>> does not have sufficient rights to all parts of a datastore >>>> section to be locked. >>> The NETCONF server's access control mechanism does not give the >>> locking user sufficient rights to any nodes to be locked. >> OK, but is this really better? > > Dismisses the unrealistic case of the server not implementing > access control. > I personally agree with you, but I was explicitly told by more then one person, not to assume that access control is always present. >>> Need a "Deadlock Avoidance" section. >> No with don't want to make this into a tutorial. OK, made it a separate chapter. > > You don't need a tutorial, but having "deadlock" show up in the > table of contents of an RFC on locking seems appropriate. Covering > it in a section on New Operations isn't. > >> Misunderstanding. We will rephrase. The issues ARE addressed in the following >> paragraphs. >> These paragraphs rather describe items that are out of scope. > > Please rephrase this, since it's very confusing. Even your > "items that are out of scope" comment here seems to say that > you are not addressing these points. > OK rephrased, hope its good. >>> Address it: If the client should not attempting operations that rely >>> on configuration that is not locked. >> We don't want to state more, this is not a tutorial. > > I don't think this turns your draft into a tutorial. > >>> Make a section on "Interactions with and ", so this is >>> more visible to the reader (and in the table of contents). >> It would be unusual to have a separate section on all the things we do not mod >> ify. > > But you _did_ change it. Global locks do not operate the same way. > If some party has a partial lock, requests for the global lock will > fail. That is already stated in 4741: "An attempt to lock the configuration MUST fail if an existing session or other entity holds a lock on any portion of the lock target." > >>> I mentioned before that having one will multiple contents and >>> multiple ? >> No, because select usually selects a group of nodes, while identifiers must al >> ways point >> out one individual node. Will be described in the definition. > > This is more to my point. The XPath select and the non-XPath > instance identifier are different datatypes. In YANG, one > would be w3c:UnionExpr and the other yang:instance-identifier > (or something like that). Where's the win of putting them in > the same argument? > >>>> Positive Response: >>>> If the device was able to satisfy the request, an is sent >>>> with a element (lock identifier) in the >>>> element. A list of locked nodes per datastore is also returned in >>>> Instance Identifier format. >>> So if I lock all sonet interfaces, I get a list of all sonet >>> interfaces? When do I need this? >> Because it might not be trivial for all XPath expressions which nodes are exac >> tly in their >> scope. > > If you wanted this, could you add another RPC, like > > rpc get-partial-lock-information { > input { > leaf lockId { ... } > } > output { > container partial-lock-information { > list lockedNode { > ... > } > } > } > } > > Don't put the price of this not-so-nice behavior on every locker. > >>>> If the :xpath capability is not supported and the XPath expression is >>>> not an Instance Identifier, the is 'invalid-value', the >>>> is ':xpath capability not supported'. >>> Show some love to your users: "invalid lock specification" >> I love users, but ??????????????? > > Sorry, I didn't make my point clearly. I make the assumption > that error messages will most likely be displayed directly to > the users of applications. Choosing text that will be lucid > to non-developers reduces the shock to the user. > >>>> Partial lock cannot be used to lock non-existent nodes, which would >>>> effectively attempt to reserve them for future use. To guarantee >>>> that a node cannot be created by some other session, the parent node >>>> SHOULD be locked, the top level node of the new section created, and >>>> then locked with another operation. After this, the >>>> lock on the parent node SHOULD be removed. >>> Since partial locks cannot be taken out for nodes that do not exist, >>> special handling is required on the client to handle scenarios the >>> locking of newly created nodes. To guarantee ... >> No, I like this better. The content seems to be the same. > > I find "reserve them for future use" confusing. I was trying to > suggest an alternative, but anything that avoids this phrase > would be better. OK. reworded. > >>> If the NETCONF server supports the :confirmed-commit capabidescribing intended usage. > > Can you explain this? Minimizing describing intended usage > doesn't sound like something that will help create interoperable > implementations. OK, will try to add usage scenarios. --------------------------------------------------------------------------- > >> RC4741 does not allow extending the lock requirement (We might be argument abo >> ut this, but >> this is the current situation.). > > We can certainly debate whether that is the current situation. > >>>> Each XPath >>>> expression MUST return a node set. >>> This is an odd sentence. What are you trying to say? Are you worried >>> that someone will think you mean predicate expressions? Do you want >>> to explicit reference the XPath spec'c production name (LocationPath >>> in section 2.0 of http://www.w3.org/TR/xpath.html). >> An XPath expression can return a node set, a boolean, a >> number or a string (see section 1. in http://www.w3.org/TR/xpath). > > True, which is why I'm suggesting you choose a more specific production > name, such as LocationPath or UnionExpr (see section 3.3 of xpath). > >>> Locking multiple datastores requires maximally pessimistic lock use, >>> right? I MUST lock it everywhere to protect myself. Seems >>> pointless. There's some logic that says the intersection of >>> boxes with :writable-running and :candidate is (or should be) nil. >>> So you should only need to lock one or the other. >> It is not stated anywhere that you can't have candidate and writable-running t >> ogether. So >> give pessimists some tools. > > Tools yes, but very expensive ones. > >>>> If the configuration data is later altered in a way that would make >>>> the original select XPath expressions evaluate to a different set of >>>> nodes, this does not affect the scope of the partial lock. >>>> >>>> XPath is only used for the creation of the partial lock. >>>> Conceptually, the scope of the lock is defined by the returned node >>>> set and not by the XPath expression. >>> These paragraphs seem to dance around some point that's not clear. >>> What to you mean "conceptually ... not by the xpath"? Why doesn't the >>> XPath expression tell you want you're trying to lock? >>> >> ------------------------------------------------------------------------------ >> -------------------------------------- > > ???? OK, merged the two related paragraphs and added an example. > >>> This last sentence is unclear (or evil). "previously locked during" >>> includes anything I had locked from previous lock requests, which >>> isn't what you want. >> Misunderstanding. It is stated that: >> unlock all parts that were previously LOCKED DURING THAT OPERATION. This indic >> ates that >> only nodes locked during that same operation are involved. > > That's the part that's unclear. "previously" and "during" are in > conflict. "previously locked" can't apply to node while the lock > operation is going on, since those nodes aren't locked until the > (atomic) lock operation completes. > OK, reworded >>> This whole issue makes me wonder why you need to support multiple >>> a > > > is identical to: > > > Yes, but it is often easier to break potentially long expressions into multiple smaller ones. However the user can still use the union if he prefers to. >>> Nodes are released from the lock when they are deleted, at which >>> point other clients or non-NETCONF mechanisms are able to recreate them. >>> >>>> A NETCONF server MUST be able to grant multiple simultaneous partial >>>> locks to a single NETCONF session. If the scope of the individual >>>> locks overlaps, nodes in the common arelity and a >>> confirmed commit is outstanding, partial lock requests for the >>> database MUST be denied, since the running datastore must be >>> rolled back if a confirming commit is not performed within the >>> appropriate time window. >> It might not be the best but it is very clear. A native English speaker has co >> mposed these >> sentences. > > I do not think this is an English issue but one of text organization. > Bulleting here isn't necessary. > >> Copy-config is valid for startup so locking is needed. If I am only interested >> in locking >> part of the datastore using partial lock is enough, no need for a global lock. > > But the startup datastore isn't required to be parsable/addressable. > It's a blob with no internal visibility. It's data in a SRAM, not > something you can run XPaths expression on. > >> (It is not really stated in 4741 that startup can not be the target of edit-co >> nfig.) > > 8.7.5.1 lists the set of operations for which is an > allowed target. is not among them. This choice was > intentional, since startup config is not required to be in memory, > addressable, parsed, open, searchable, or available for XPath > expressions. It's typically a section of SRAM or flash; you can > read it or write it, but that's about it. - even if only copy-config is supported locking is relevant. - the text of 4741 states what must be supported, but it says nothing about edit-config. > >>>> module netconf-partial-lock { >>> s/netconf/ietf-netconf/ >> Ask work group !!! > > Isn't that what review comments do? Do I need to open formal issues > for items that need to be addressed? OK, will have ietf > > Thanks, > Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf a MUST be locked until all of >>>> the locks are released. >>> Nodes locked under multiple overlapping locks remain locked until >>> all such locks are released. >> Less clear, it does not state that partial locks MAY overlap. > > Keep the first sentence. Repair the second one. Reworded paragraph. > >>>> A partial lock operation MUST fail if: >>>> >>>> o Any NETCONF session (including the current session) owns the >>>> global lock on any target datastore. >>>> >>>> o Any part of the scope to be locked is already locked by another >>>> management session/protocol, including other NETCONF sessions >>>> using the or any other non-NETCONF management >>>> method. >>>> >>>> o The NETCONF server implements access control, and the locking user >>>> does not have sufficient rights to all parts of a datastore >>>> section to be locked. >>> The NETCONF server's access control mechanism does not give the >>> locking user sufficient rights to any nodes to be locked. >> OK, but is this really better? > > Dismisses the unrealistic case of the server not implementing > access control. > I personally agree with you, but I was explicitly told by more then one person, not to assume that access control is always present. >>> Need a "Deadlock Avoidance" section. >> No with don't want to make this into a tutorial. OK, made it a separate chapter. > > You don't need a tutorial, but having "deadlock" show up in the > table of contents of an RFC on locking seems appropriate. Covering > it in a section on New Operations isn't. > >> Misunderstanding. We will rephrase. The issues ARE addressed in the following >> paragraphs. >> These paragraphs rather describe items that are out of scope. > > Please rephrase this, since it's very confusing. Even your > "items that are out of scope" comment here seems to say that > you are not addressing these points. > OK rephrased, hope its good. >>> Address it: If the client should not attempting operations that rely >>> on configuration that is not locked. >> We don't want to state more, this is not a tutorial. > > I don't think this turns your draft into a tutorial. > >>> Make a section on "Interactions with and ", so this is >>> more visible to the reader (and in the table of contents). >> It would be unusual to have a separate section on all the things we do not mod >> ify. > > But you _did_ change it. Global locks do not operate the same way. > If some party has a partial lock, requests for the global lock will > fail. That is already stated in 4741: "An attempt to lock the configuration MUST fail if an existing session or other entity holds a lock on any portion of the lock target." > >>> I mentioned before that having one will multiple contents and >>> multiple ? >> No, because select usually selects a group of nodes, while identifiers must al >> ways point >> out one individual node. Will be described in the definition. > > This is more to my point. The XPath select and the non-XPath > instance identifier are different datatypes. In YANG, one > would be w3c:UnionExpr and the other yang:instance-identifier > (or something like that). Where's the win of putting them in > the same argument? > >>>> Positive Response: >>>> If the device was able to satisfy the request, an is sent >>>> with a element (lock identifier) in the >>>> element. A list of locked nodes per datastore is also returned in >>>> Instance Identifier format. >>> So if I lock all sonet interfaces, I get a list of all sonet >>> interfaces? When do I need this? >> Because it might not be trivial for all XPath expressions which nodes are exac >> tly in their >> scope. > > If you wanted this, could you add another RPC, like > > rpc get-partial-lock-information { > input { > leaf lockId { ... } > } > output { > container partial-lock-information { > list lockedNode { > ... > } > } > } > } > > Don't put the price of this not-so-nice behavior on every locker. > >>>> If the :xpath capability is not supported and the XPath expression is >>>> not an Instance Identifier, the is 'invalid-value', the >>>> is ':xpath capability not supported'. >>> Show some love to your users: "invalid lock specification" >> I love users, but ??????????????? > > Sorry, I didn't make my point clearly. I make the assumption > that error messages will most likely be displayed directly to > the users of applications. Choosing text that will be lucid > to non-developers reduces the shock to the user. > >>>> Partial lock cannot be used to lock non-existent nodes, which would >>>> effectively attempt to reserve them for future use. To guarantee >>>> that a node cannot be created by some other session, the parent node >>>> SHOULD be locked, the top level node of the new section created, and >>>> then locked with another operation. After this, the >>>> lock on the parent node SHOULD be removed. >>> Since partial locks cannot be taken out for nodes that do not exist, >>> special handling is required on the client to handle scenarios the >>> locking of newly created nodes. To guarantee ... >> No, I like this better. The content seems to be the same. > > I find "reserve them for future use" confusing. I was trying to > suggest an alternative, but anything that avoids this phrase > would be better. OK. reworded. > >>> If the NETCONF server supports the :confirmed-commit capability and a >>> confirmed commit is outstanding, partial lock requests for the >>> database MUST be denied, since the running datastore must be >>> rolled back if a confirming commit is not performed within the >>> appropriate time window. >> It might not be the best but it is very clear. A native English speaker has co >> mposed these >> sentences. > > I do not think this is an English issue but one of text organization. > Bulleting here isn't necessary. > >> Copy-config is valid for startup so locking is needed. If I am only interested >> in locking >> part of the datastore using partial lock is enough, no need for a global lock. > > But the startup datastore isn't required to be parsable/addressable. > It's a blob with no internal visibility. It's data in a SRAM, not > something you can run XPaths expression on. > >> (It is not really stated in 4741 that startup can not be the target of edit-co >> nfig.) > > 8.7.5.1 lists the set of operations for which is an > allowed target. is not among them. This choice was > intentional, since startup config is not required to be in memory, > addressable, parsed, open, searchable, or available for XPath > expressions. It's typically a section of SRAM or flash; you can > read it or write it, but that's about it. - even if only copy-config is supported locking is relevant. - the text of 4741 states what must be supported, but it says nothing about edit-config. > >>>> module netconf-partial-lock { >>> s/netconf/ietf-netconf/ >> Ask work group !!! > > Isn't that what review comments do? Do I need to open formal issues > for items that need to be addressed? OK, will have ietf > > Thanks, > Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 00:08: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 65CC93A6A31; Wed, 26 Nov 2008 00:08:03 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98DF3A6A31 for ; Wed, 26 Nov 2008 00:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VohS4J9nQomE for ; Wed, 26 Nov 2008 00:08:02 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id B19823A6803 for ; Wed, 26 Nov 2008 00:08:01 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mAQ87rIS026560 for ; Wed, 26 Nov 2008 09:07:53 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 09:07:53 +0100 Message-ID: <492D0377.3000701@s3group.com> Date: Wed, 26 Nov 2008 09:06:15 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: netconf@ietf.org X-OriginalArrivalTime: 26 Nov 2008 08:07:53.0382 (UTC) FILETIME=[1513DC60:01C94F9E] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Wed, 26 Nov 2008 09:07:54 +0100 (CET) Subject: Re: [Netconf] rpc-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 Hi, My apologize that I don't respond directly to the Martin's mail. I was looking through the mail archive and took interest in this topic. IMO, this is one of the fundamental problem in the NETCONF standard's specification. I can imagine a lot of cases when the underlying system may return an error during "get" type operation (addressing non-existing item, no access to the addressed item, communication error, device error). The standard allows returning infinite number of the rpc-errors before the element. As you mentioned it may cause buffering a huge amount of data in the memory. But even so, I think a collection of the rpc-errors (other than syntax ones) before the element would not say enough where the problems exist. Sending rpc-errors inline in the structure may help, however it's conceivable that many different reasons of the errors cause that rpc-errors appears at the same level of the structure. It means that a client has to rely on the rpc-error's content rather than place of its appearing. Moreover, in this case assumption that rpc-errors can appear in one fixed place may make the client's code less complicated. Putting rpc-error inline in the structure is valid from the NETCONF XSD schema point of view but I wonder if authors of the RFC were considering such case during standard specification. Regards, Tomasz Mikolajczyk The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 00:08: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 65CC93A6A31; Wed, 26 Nov 2008 00:08:03 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98DF3A6A31 for ; Wed, 26 Nov 2008 00:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VohS4J9nQomE for ; Wed, 26 Nov 2008 00:08:02 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id B19823A6803 for ; Wed, 26 Nov 2008 00:08:01 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mAQ87rIS026560 for ; Wed, 26 Nov 2008 09:07:53 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 09:07:53 +0100 Message-ID: <492D0377.3000701@s3group.com> Date: Wed, 26 Nov 2008 09:06:15 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: netconf@ietf.org X-OriginalArrivalTime: 26 Nov 2008 08:07:53.0382 (UTC) FILETIME=[1513DC60:01C94F9E] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Wed, 26 Nov 2008 09:07:54 +0100 (CET) Subject: Re: [Netconf] rpc-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 Hi, My apologize that I don't respond directly to the Martin's mail. I was looking through the mail archive and took interest in this topic. IMO, this is one of the fundamental problem in the NETCONF standard's specification. I can imagine a lot of cases when the underlying system may return an error during "get" type operation (addressing non-existing item, no access to the addressed item, communication error, device error). The standard allows returning infinite number of the rpc-errors before the element. As you mentioned it may cause buffering a huge amount of data in the memory. But even so, I think a collection of the rpc-errors (other than syntax ones) before the element would not say enough where the problems exist. Sending rpc-errors inline in the structure may help, however it's conceivable that many different reasons of the errors cause that rpc-errors appears at the same level of the structure. It means that a client has to rely on the rpc-error's content rather than place of its appearing. Moreover, in this case assumption that rpc-errors can appear in one fixed place may make the client's code less complicated. Putting rpc-error inline in the structure is valid from the NETCONF XSD schema point of view but I wonder if authors of the RFC were considering such case during standard specification. Regards, Tomasz Mikolajczyk The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 04:48: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 5972228C1D3; Wed, 26 Nov 2008 04:48:37 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C9728C1D3 for ; Wed, 26 Nov 2008 04:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExQ0NQ1HS3Wq for ; Wed, 26 Nov 2008 04:48:35 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 8C9FA28C170 for ; Wed, 26 Nov 2008 04:48:33 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mAQCmN7B000383 for ; Wed, 26 Nov 2008 13:48:26 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 13:48:23 +0100 Message-ID: <492D4534.9030108@s3group.com> Date: Wed, 26 Nov 2008 13:46:44 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: netconf@ietf.org X-OriginalArrivalTime: 26 Nov 2008 12:48:23.0361 (UTC) FILETIME=[4486DB10:01C94FC5] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Wed, 26 Nov 2008 13:48:27 +0100 (CET) Subject: [Netconf] double create-subscription operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, It's not obvious from the RFC 5277 how a NETCONF server should behave when an already subscribed for notification client sends the create-subscription once again. I see two possibilities: 1) existing subscription has to be somehow updated, i.e apply new filters, change stop time, etc. Sections 2.3 and 3.5 say about lifetime but updating doesn't mean recreating, i.e. finishing existing subscription and creating a new one. But I guess in an implementation it would mean recreating 2) error must be returned IMO, the first one seems to be more useful as it would be possible to change existing subscription's parameters without need of creating a new session or waiting for the existing subscription's dead. However, the second option is simpler. Regards, Tomasz Mikolajczyk The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional querFrom netconf-bounces@ietf.org Wed Nov 26 04:48: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 5972228C1D3; Wed, 26 Nov 2008 04:48:37 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C9728C1D3 for ; Wed, 26 Nov 2008 04:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExQ0NQ1HS3Wq for ; Wed, 26 Nov 2008 04:48:35 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 8C9FA28C170 for ; Wed, 26 Nov 2008 04:48:33 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mAQCmN7B000383 for ; Wed, 26 Nov 2008 13:48:26 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 13:48:23 +0100 Message-ID: <492D4534.9030108@s3group.com> Date: Wed, 26 Nov 2008 13:46:44 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: netconf@ietf.org X-OriginalArrivalTime: 26 Nov 2008 12:48:23.0361 (UTC) FILETIME=[4486DB10:01C94FC5] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Wed, 26 Nov 2008 13:48:27 +0100 (CET) Subject: [Netconf] double create-subscription operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, It's not obvious from the RFC 5277 how a NETCONF server should behave when an already subscribed for notification client sends the create-subscription once again. I see two possibilities: 1) existing subscription has to be somehow updated, i.e apply new filters, change stop time, etc. Sections 2.3 and 3.5 say about lifetime but updating doesn't mean recreating, i.e. finishing existing subscription and creating a new one. But I guess in an implementation it would mean recreating 2) error must be returned IMO, the first one seems to be more useful as it would be possible to change existing subscription's parameters without need of creating a new session or waiting for the existing subscription's dead. However, the second option is simpler. Regards, Tomasz Mikolajczyk The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additionaies to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf l queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 04:52:22 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 031A628C172; Wed, 26 Nov 2008 04:52:22 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294FD28C172 for ; Wed, 26 Nov 2008 04:52:20 -0800 (PST) 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 cK9oPT3ntQji for ; Wed, 26 Nov 2008 04:52:19 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6062F28C171 for ; Wed, 26 Nov 2008 04:52:18 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 48FC476C310; Wed, 26 Nov 2008 13:52:15 +0100 (CET) Date: Wed, 26 Nov 2008 13:52:15 +0100 (CET) Message-Id: <20081126.135215.190449157.mbj@tail-f.com> To: tomasz.mikolajczyk@s3group.com From: Martin Bjorklund In-Reply-To: <492D4534.9030108@s3group.com> References: <492D4534.9030108@s3group.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] double create-subscription operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Tomasz Mikolajczyk wrote: > It's not obvious from the RFC 5277 how a NETCONF server should behave > when an already subscribed for notification client sends the > create-subscription once again. I see two possibilities: See section 6.5: When a is sent while another subscription is active on that session, the following error will be returned: ... /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 04:52:22 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 031A628C172; Wed, 26 Nov 2008 04:52:22 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294FD28C172 for ; Wed, 26 Nov 2008 04:52:20 -0800 (PST) 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 cK9oPT3ntQji for ; Wed, 26 Nov 2008 04:52:19 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6062F28C171 for ; Wed, 26 Nov 2008 04:52:18 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 48FC476C310; Wed, 26 Nov 2008 13:52:15 +0100 (CET) Date: Wed, 26 Nov 2008 13:52:15 +0100 (CET) Message-Id: <20081126.135215.190449157.mbj@tail-f.com> To: tomasz.mikolajczyk@s3group.com From: Martin Bjorklund In-Reply-To: <492D4534.9030108@s3group.com> References: <492D4534.9030108@s3group.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] double create-subscription operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Tomasz Mikolajczyk wrote: > It's not obvious from the RFC 5277 how a NETCONF server should behave > when an already subscribed for notification client sends the > create-subscription once again. I see two possibilities: See section 6.5: When a is sent while another subscription is active on that session, the following error will be returned: ... /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 05:04:08 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 48EA828C172; Wed, 26 Nov 2008 05:04:08 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CF8728C172 for ; Wed, 26 Nov 2008 05:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3m9SU8SjUq3J for ; Wed, 26 Nov 2008 05:04:06 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 2F41128C12E for ; Wed, 26 Nov 2008 05:04:04 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mAQD3v51000615; Wed, 26 Nov 2008 14:03:57 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 14:03:57 +0100 Message-ID: <492D48DA.7010706@s3group.com> Date: Wed, 26 Nov 2008 14:02:18 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: Martin Bjorklund References: <492D4534.9030108@s3group.com> <20081126.135215.190449157.mbj@tail-f.com> In-Reply-To: <20081126.135215.190449157.mbj@tail-f.com> X-OriginalArrivalTime: 26 Nov 2008 13:03:57.0830 (UTC) FILETIME=[71838260:01C94FC7] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Wed, 26 Nov 2008 14:03:59 +0100 (CET) Cc: netconf@ietf.org Subject: Re: [Netconf] double create-subscription operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Tomasz Mikolajczyk wrote: >> It's not obvious from the RFC 5277 how a NETCONF server should behave >> when an already subscribed for notification client sends the >> create-subscription once again. I see two possibilities: > > See section 6.5: > > When a is sent while another subscription is > active on that session, the following error will be returned: > > ... Sorry, I missed it. Thanks. Regards, Tomasz Mikolajczyk The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 05:04:08 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 48EA828C172; Wed, 26 Nov 2008 05:04:08 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CF8728C172 for ; Wed, 26 Nov 2008 05:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3m9SU8SjUq3J for ; Wed, 26 Nov 2008 05:04:06 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 2F41128C12E for ; Wed, 26 Nov 2008 05:04:04 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mAQD3v51000615; Wed, 26 Nov 2008 14:03:57 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 14:03:57 +0100 Message-ID: <492D48DA.7010706@s3group.com> Date: Wed, 26 Nov 2008 14:02:18 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: Martin Bjorklund References: <492D4534.9030108@s3group.com> <20081126.135215.190449157.mbj@tail-f.com> In-Reply-To: <20081126.135215.190449157.mbj@tail-f.com> X-OriginalArrivalTime: 26 Nov 2008 13:03:57.0830 (UTC) FILETIME=[71838260:01C94FC7] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Wed, 26 Nov 2008 14:03:59 +0100 (CET) Cc: netconf@ietf.org Subject: Re: [Netconf] double create-subscription operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Tomasz Mikolajczyk wrote: >> It's not obvious from the RFC 5277 how a NETCONF server should behave >> when an already subscribed for notification client sends the >> create-subscription once again. I see two possibilities: > > See section 6.5: > > When a is sent while another subscription is > active on that session, the following error will be returned: > > ... Sorry, I missed it. Thanks. Regards, Tomasz Mikolajczyk The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 07:42:16 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 EA0E73A6A19; Wed, 26 Nov 2008 07:42:16 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ADAF3A6A19 for ; Wed, 26 Nov 2008 07:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.125, 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 IPiE8VfHUKcY for ; Wed, 26 Nov 2008 07:42:14 -0800 (PST) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id E7B0A3A679F for ; Wed, 26 Nov 2008 07:42:14 -0800 (PST) Received: (qmail 31665 invoked from network); 26 Nov 2008 15:42:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 26 Nov 2008 15:42:11 -0000 X-YMail-OSG: oQjvqZQVM1kNq3k.PyXAycWpQ0b0tu2zsso8as3pc0.kHUo57dX2UwnYJpZYFGPaWYQ_Z9PYBYdlmLJmfAvqOBi.5AeQjBy7kq5.YWACBELb1E.YVuZbvsMP3mc7ICRUV1w- X-Yahoo-Newman-Property: ymail-3 Message-ID: <492D6E51.6070905@netconfcentral.com> Date: Wed, 26 Nov 2008 07:42:09 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETCONF Subject: [Netconf] XPath in RFC 4741 X-BeenThere: netconf@ietf.org X-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, The details on XPath filtering in 8.9.5.1 are not that clear. There is only a request in the example, but no reply: Note the bug in the example -- the select string should start with an absolute-path (/top instead of top). Note the lack of namespace declarations also. Is this the correct reply? Does the node-set result get expanded back to root (A), or just encoded as a node-set (B)? (A) fred
...
... (B) fred
...
... What about something like select="//name"? (B) fred barney eth0 eth1 Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 07:42: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 EA0E73A6A19; Wed, 26 Nov 2008 07:42:16 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ADAF3A6A19 for ; Wed, 26 Nov 2008 07:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.125, 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 IPiE8VfHUKcY for ; Wed, 26 Nov 2008 07:42:14 -0800 (PST) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id E7B0A3A679F for ; Wed, 26 Nov 2008 07:42:14 -0800 (PST) Received: (qmail 31665 invoked from network); 26 Nov 2008 15:42:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 26 Nov 2008 15:42:11 -0000 X-YMail-OSG: oQjvqZQVM1kNq3k.PyXAycWpQ0b0tu2zsso8as3pc0.kHUo57dX2UwnYJpZYFGPaWYQ_Z9PYBYdlmLJmfAvqOBi.5AeQjBy7kq5.YWACBELb1E.YVuZbvsMP3mc7ICRUV1w- X-Yahoo-Newman-Property: ymail-3 Message-ID: <492D6E51.6070905@netconfcentral.com> Date: Wed, 26 Nov 2008 07:42:09 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: NETCONF Subject: [Netconf] XPath in RFC 4741 X-BeenThere: netconf@ietf.org X-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, The details on XPath filtering in 8.9.5.1 are not that clear. There is only a request in the example, but no reply: Note the bug in the example -- the select string should start with an absolute-path (/top instead of top). Note the lack of namespace declarations also. Is this the correct reply? Does the node-set result get expanded back to root (A), or just encoded as a node-set (B)? (A) fred
...
... (B) fred
...
... What about something like select="//name"? (B) fred barney eth0 eth1 Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 08:00: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 9216B28C130; Wed, 26 Nov 2008 08:00:01 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78E3E28C12C for ; Wed, 26 Nov 2008 08:00:00 -0800 (PST) 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 yhekiGD50+cB for ; Wed, 26 Nov 2008 07:59:59 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 92F9B28C130 for ; Wed, 26 Nov 2008 07:59:59 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1EB4776C310; Wed, 26 Nov 2008 16:59:56 +0100 (CET) Date: Wed, 26 Nov 2008 16:59:55 +0100 (CET) Message-Id: <20081126.165955.251805489.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <492D6E51.6070905@netconfcentral.com> References: <492D6E51.6070905@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] XPath in RFC 4741 X-BeenThere: netconf@ietf.org X-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, > > The details on XPath filtering in 8.9.5.1 are not > that clear. > > There is only a request in the example, but no reply: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > Note the bug in the example -- the select string should start > with an absolute-path (/top instead of top). Hmmm.. while I agree that the example should use "/top/...", I think it is legal to do "top/..." - this will then be evaluated relative to the context node which is the conceptual node. > Note the lack of > namespace declarations also. Yes, now added to our list of things to fix. > Is this the correct reply? Does the node-set result get > expanded back to root (A), or just encoded as a node-set (B)? IMO and IMI (in my implementation) it must be A. We want the xpath notation to work as the subtree filter, and we want the returned instance document to be a proper subset of the complete get-config output. (imagine what the XSD to validate (B) would look like...) > What about something like select="//name"? > > (B) > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > fred > barney > eth0 > eth1 > > With (A) you'd get: fred barney eth0 eth1 /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 08:00: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 9216B28C130; Wed, 26 Nov 2008 08:00:01 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78E3E28C12C for ; Wed, 26 Nov 2008 08:00:00 -0800 (PST) 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 yhekiGD50+cB for ; Wed, 26 Nov 2008 07:59:59 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 92F9B28C130 for ; Wed, 26 Nov 2008 07:59:59 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1EB4776C310; Wed, 26 Nov 2008 16:59:56 +0100 (CET) Date: Wed, 26 Nov 2008 16:59:55 +0100 (CET) Message-Id: <20081126.165955.251805489.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <492D6E51.6070905@netconfcentral.com> References: <492D6E51.6070905@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] XPath in RFC 4741 X-BeenThere: netconf@ietf.org X-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, > > The details on XPath filtering in 8.9.5.1 are not > that clear. > > There is only a request in the example, but no reply: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > Note the bug in the example -- the select string should start > with an absolute-path (/top instead of top). Hmmm.. while I agree that the example should use "/top/...", I think it is legal to do "top/..." - this will then be evaluated relative to the context node which is the conceptual node. > Note the lack of > namespace declarations also. Yes, now added to our list of things to fix. > Is this the correct reply? Does the node-set result get > expanded back to root (A), or just encoded as a node-set (B)? IMO and IMI (in my implementation) it must be A. We want the xpath notation to work as the subtree filter, and we want the returned instance document to be a proper subset of the complete get-config output. (imagine what the XSD to validate (B) would look like...) > What about something like select="//name"? > > (B) > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > fred > barney > eth0 > eth1 > > With (A) you'd get: fred barney eth0 eth1 /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 08:13: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 C45143A6B59; Wed, 26 Nov 2008 08:13:18 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EAC73A6B59 for ; Wed, 26 Nov 2008 08:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8tRfUscT0rQ for ; Wed, 26 Nov 2008 08:13:15 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 892383A68D1 for ; Wed, 26 Nov 2008 08:13:14 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mAQGD4gu008000; Wed, 26 Nov 2008 17:13:04 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 17:13:04 +0100 Message-ID: <492D752C.5050605@s3group.com> Date: Wed, 26 Nov 2008 17:11:24 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: Andy Bierman References: <492D6E51.6070905@netconfcentral.com> In-Reply-To: <492D6E51.6070905@netconfcentral.com> X-OriginalArrivalTime: 26 Nov 2008 16:13:04.0260 (UTC) FILETIME=[DC835440:01C94FE1] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Wed, 26 Nov 2008 17:13:06 +0100 (CET) Cc: NETCONF Subject: Re: [Netconf] XPath in RFC 4741 X-BeenThere: netconf@ietf.org X-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, Andy Bierman wrote: > What about something like select="//name"? > > (B) > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > fred > barney > eth0 > eth1 > > > > > > Andy > Such response is inconsistent with the subtree filtering rules and rather should be: fred barney eth0 eth1 Regards, Tomasz Mikolajczyk The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 08:13: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 C45143A6B59; Wed, 26 Nov 2008 08:13:18 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EAC73A6B59 for ; Wed, 26 Nov 2008 08:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8tRfUscT0rQ for ; Wed, 26 Nov 2008 08:13:15 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 892383A68D1 for ; Wed, 26 Nov 2008 08:13:14 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mAQGD4gu008000; Wed, 26 Nov 2008 17:13:04 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 17:13:04 +0100 Message-ID: <492D752C.5050605@s3group.com> Date: Wed, 26 Nov 2008 17:11:24 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: Andy Bierman References: <492D6E51.6070905@netconfcentral.com> In-Reply-To: <492D6E51.6070905@netconfcentral.com> X-OriginalArrivalTime: 26 Nov 2008 16:13:04.0260 (UTC) FILETIME=[DC835440:01C94FE1] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Wed, 26 Nov 2008 17:13:06 +0100 (CET) Cc: NETCONF Subject: Re: [Netconf] XPath in RFC 4741 X-BeenThere: netconf@ietf.org X-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, Andy Bierman wrote: > What about something like select="//name"? > > (B) > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > fred > barney > eth0 > eth1 > > > > > > Andy > Such response is inconsistent with the subtree filtering rules and rather should be: fred barney eth0 eth1 Regards, Tomasz Mikolajczyk The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 09:11: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 F042E3A6B65; Wed, 26 Nov 2008 09:11:24 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9423A6B65 for ; Wed, 26 Nov 2008 09:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.812 X-Spam-Level: X-Spam-Status: No, score=0.812 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_20=-0.74, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDKjY6a1tlc2 for ; Wed, 26 Nov 2008 09:11:23 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 858523A6836 for ; Wed, 26 Nov 2008 09:11:23 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1L5Nv5-00012l-Ik for netconf@ietf.org; Wed, 26 Nov 2008 18:11:19 +0100 Message-ID: <73A93A6B318A47F5B4BC683D251C43E8@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Wed, 26 Nov 2008 18:10:53 +0100 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] confirm WG consensus on potential new WG work-item: 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 WG participants, At our NetConf Session at IETF73, the people in the room expressed strong support for asking our ADs to amend our WG charter (if the work is not already covered by the current charter) to work on a capability "with-defaults". The majority wants this to be a separate WG document (draft). The majority agreed with using draft-bierman-netconf-with-defaults-01.txt as the starting point for this work. The WG chairs consider this to be WG consensus. If anyone on the mailing list does not agree, please speak up before Dec 3rd 2008. That is one week. We want to try and get updated charter to IESG before X-mas. The WG chairs will discuss if a charter change is needed with the AD, and if so, we will circulate draft charter text for consensus checking. Bert and Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 09:11: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 F042E3A6B65; Wed, 26 Nov 2008 09:11:24 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9423A6B65 for ; Wed, 26 Nov 2008 09:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.812 X-Spam-Level: X-Spam-Status: No, score=0.812 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_20=-0.74, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDKjY6a1tlc2 for ; Wed, 26 Nov 2008 09:11:23 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 858523A6836 for ; Wed, 26 Nov 2008 09:11:23 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1L5Nv5-00012l-Ik for netconf@ietf.org; Wed, 26 Nov 2008 18:11:19 +0100 Message-ID: <73A93A6B318A47F5B4BC683D251C43E8@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Wed, 26 Nov 2008 18:10:53 +0100 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] confirm WG consensus on potential new WG work-item: 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 WG participants, At our NetConf Session at IETF73, the people in the room expressed strong support for asking our ADs to amend our WG charter (if the work is not already covered by the current charter) to work on a capability "with-defaults". The majority wants this to be a separate WG document (draft). The majority agreed with using draft-bierman-netconf-with-defaults-01.txt as the starting point for this work. The WG chairs consider this to be WG consensus. If anyone on the mailing list does not agree, please speak up before Dec 3rd 2008. That is one week. We want to try and get updated charter to IESG before X-mas. The WG chairs will discuss if a charter change is needed with the AD, and if so, we will circulate draft charter text for consensus checking. Bert and Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 09: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 2BF8E3A6C10; Wed, 26 Nov 2008 09:12:35 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 594593A6C10 for ; Wed, 26 Nov 2008 09:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.118, 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 U7d4jMLjrTQl for ; Wed, 26 Nov 2008 09:12:33 -0800 (PST) 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 9ECE23A6836 for ; Wed, 26 Nov 2008 09:12:33 -0800 (PST) Received: (qmail 15585 invoked from network); 26 Nov 2008 17:12:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 26 Nov 2008 17:12:29 -0000 X-YMail-OSG: rVx7hgQVM1nwlCg.wAgiC1y9sNvrNKiq_VSj3nXJVvQRTuMDsofA8iLPhzc9daXlrBHKOAbZf4.OqDdJ2K4S_CsuhHmuxt6BsoG8Lc1JR0uIp1X0Yyi0ryXQbdNjvyFIDBA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <492D837C.3020204@netconfcentral.com> Date: Wed, 26 Nov 2008 09:12:28 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Tomasz Mikolajczyk References: <492D6E51.6070905@netconfcentral.com> <492D752C.5050605@s3group.com> In-Reply-To: <492D752C.5050605@s3group.com> Cc: NETCONF Subject: Re: [Netconf] XPath in RFC 4741 X-BeenThere: netconf@ietf.org X-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 Tomasz Mikolajczyk wrote: > Hi, > > Andy Bierman wrote: > >> What about something like select="//name"? >> >> (B) >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> fred >> barney >> eth0 >> eth1 >> >> >> >> >> >> Andy >> > > Such response is inconsistent with the subtree filtering rules and > rather should be: > Where does it say in 4741 that XPath filtered output looks the same as subtree-filtered output? RFC 4741 seems to say "use XPath and do what XPath says to do". That was the intent of the WG at the time it was written. It seems to me that XPath 1.0 does not return all the ancestor nodes in a node-set result, but rather the requested nodes. The RFC does not say what to do if the select expression is not a node-set, but another result type (string, boolean or number). I assume an empty response will be given in those cases. IMO, this is a serious issue. One could argue that off-the-shelf XPath tools are rendered useless if the agent returns (A) instead of (B). I can see how most XPath is intended to be used in some application context, where something is being done to the result nodes. The natural NETCONF application is 'xedit': path = "/interfaces/interface[name='fred']/mtu" confignode = xget(select=path) if confignode < 1518: confignode = 1518 xedit(select=path, operation='replace', value=confignode) In this hypothetical application, it makes much more sense to do what XPath says instead of making up rules about returning all the ancestor nodes. The xedit syntax does not have to be aligned with the XPath filtered retrieval output, but it makes code easier for some things (and harder for others). XPath set is another power saw that must be used really carefully: xedit(select="/interfaces/interface/mtu", value=1518) Or even: lockid = partial-lock(select="/interfaces/interface/mtu") if lockid: xedit(select="/interfaces/interface/mtu", value=1518) partial-unlock(lock-id) > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > fred > > > barney > > > > eth0 > > > eth1 > > > > > > Regards, > Tomasz Mikolajczyk > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 09: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 2BF8E3A6C10; Wed, 26 Nov 2008 09:12:35 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 594593A6C10 for ; Wed, 26 Nov 2008 09:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.118, 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 U7d4jMLjrTQl for ; Wed, 26 Nov 2008 09:12:33 -0800 (PST) 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 9ECE23A6836 for ; Wed, 26 Nov 2008 09:12:33 -0800 (PST) Received: (qmail 15585 invoked from network); 26 Nov 2008 17:12:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 26 Nov 2008 17:12:29 -0000 X-YMail-OSG: rVx7hgQVM1nwlCg.wAgiC1y9sNvrNKiq_VSj3nXJVvQRTuMDsofA8iLPhzc9daXlrBHKOAbZf4.OqDdJ2K4S_CsuhHmuxt6BsoG8Lc1JR0uIp1X0Yyi0ryXQbdNjvyFIDBA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <492D837C.3020204@netconfcentral.com> Date: Wed, 26 Nov 2008 09:12:28 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Tomasz Mikolajczyk References: <492D6E51.6070905@netconfcentral.com> <492D752C.5050605@s3group.com> In-Reply-To: <492D752C.5050605@s3group.com> Cc: NETCONF Subject: Re: [Netconf] XPath in RFC 4741 X-BeenThere: netconf@ietf.org X-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 Tomasz Mikolajczyk wrote: > Hi, > > Andy Bierman wrote: > >> What about something like select="//name"? >> >> (B) >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> fred >> barney >> eth0 >> eth1 >> >> >> >> >> >> Andy >> > > Such response is inconsistent with the subtree filtering rules and > rather should be: > Where does it say in 4741 that XPath filtered output looks the same as subtree-filtered output? RFC 4741 seems to say "use XPath and do what XPath says to do". That was the intent of the WG at the time it was written. It seems to me that XPath 1.0 does not return all the ancestor nodes in a node-set result, but rather the requested nodes. The RFC does not say what to do if the select expression is not a node-set, but another result type (string, boolean or number). I assume an empty response will be given in those cases. IMO, this is a serious issue. One could argue that off-the-shelf XPath tools are rendered useless if the agent returns (A) instead of (B). I can see how most XPath is intended to be used in some application context, where something is being done to the result nodes. The natural NETCONF application is 'xedit': path = "/interfaces/interface[name='fred']/mtu" confignode = xget(select=path) if confignode < 1518: confignode = 1518 xedit(select=path, operation='replace', value=confignode) In this hypothetical application, it makes much more sense to do what XPath says instead of making up rules about returning all the ancestor nodes. The xedit syntax does not have to be aligned with the XPath filtered retrieval output, but it makes code easier for some things (and harder for others). XPath set is another power saw that must be used really carefully: xedit(select="/interfaces/interface/mtu", value=1518) Or even: lockid = partial-lock(select="/interfaces/interface/mtu") if lockid: xedit(select="/interfaces/interface/mtu", value=1518) partial-unlock(lock-id) > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > fred > > > barney > > > > eth0 > > > eth1 > > > > > > Regards, > Tomasz Mikolajczyk > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 09:56: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 1FD3F3A6C17; Wed, 26 Nov 2008 09:56:38 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0BC73A6C17 for ; Wed, 26 Nov 2008 09:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.748 X-Spam-Level: X-Spam-Status: No, score=0.748 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_05=-1.11, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSq76Iz+0bIh for ; Wed, 26 Nov 2008 09:56:36 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 3675F3A6943 for ; Wed, 26 Nov 2008 09:56:36 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1L5Ocr-0008Fw-4a for netconf@ietf.org; Wed, 26 Nov 2008 18:56:33 +0100 Message-ID: <4D7EEB1103FA450A907208A7CCFACC4E@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Wed, 26 Nov 2008 18:56:09 +0100 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] confirm WG consensus on potential new WG work-item: notification X-BeenThere: netconf@ietf.org X-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 participants, At our NetConf Session at IETF73, the people in the room expressed strong support for the following statements: - We do not want to define extensive Notification content NOW - We just want to define content for notifications that we URGENTLY need now (within the next year). That is one or two notifications - Less urgent notification content we can define once the NETMOD results become available The WG chairs consider this to be WG consensus. If anyone on the mailing list does not agree, please speak up before Dec 3rd 2008. That is one week. We want to try and get updated charter to IESG before X-mas. The WG chairs do not want to consider draft-chisholm-netconf-not-content-00.txt as a starting point. The reason being that it wants to do much more than the minimal approach that is expressed above. The WG chairs will propose/draft new charter text that we will circulate for consensus checking. Once we have such a draft text, we will also call for volunteers to become editors of the document. Bert and Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 09:56: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 1FD3F3A6C17; Wed, 26 Nov 2008 09:56:38 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0BC73A6C17 for ; Wed, 26 Nov 2008 09:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.748 X-Spam-Level: X-Spam-Status: No, score=0.748 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_05=-1.11, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSq76Iz+0bIh for ; Wed, 26 Nov 2008 09:56:36 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 3675F3A6943 for ; Wed, 26 Nov 2008 09:56:36 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1L5Ocr-0008Fw-4a for netconf@ietf.org; Wed, 26 Nov 2008 18:56:33 +0100 Message-ID: <4D7EEB1103FA450A907208A7CCFACC4E@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Wed, 26 Nov 2008 18:56:09 +0100 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] confirm WG consensus on potential new WG work-item: notification X-BeenThere: netconf@ietf.org X-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 participants, At our NetConf Session at IETF73, the people in the room expressed strong support for the following statements: - We do not want to define extensive Notification content NOW - We just want to define content for notifications that we URGENTLY need now (within the next year). That is one or two notifications - Less urgent notification content we can define once the NETMOD results become available The WG chairs consider this to be WG consensus. If anyone on the mailing list does not agree, please speak up before Dec 3rd 2008. That is one week. We want to try and get updated charter to IESG before X-mas. The WG chairs do not want to consider draft-chisholm-netconf-not-content-00.txt as a starting point. The reason being that it wants to do much more than the minimal approach that is expressed above. The WG chairs will propose/draft new charter text that we will circulate for consensus checking. Once we have such a draft text, we will also call for volunteers to become editors of the document. Bert and Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 09:56: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 515A53A6C33; Wed, 26 Nov 2008 09:56:39 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31523A6C17 for ; Wed, 26 Nov 2008 09:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTuMB9vfHxsC for ; Wed, 26 Nov 2008 09:56:37 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 2B5613A6943 for ; Wed, 26 Nov 2008 09:56:37 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1L5Ocq-0008Fw-LM for netconf@ietf.org; Wed, 26 Nov 2008 18:56:32 +0100 Message-ID: <379908FBBB4F4797A0BDC9A7EBD8123C@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Wed, 26 Nov 2008 18:55:41 +0100 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] confirm WG consensus on potential new WG work-item: rfc4741bis X-BeenThere: netconf@ietf.org X-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 participants, At our NetConf Session at IETF73, the people in the room expressed strong support for working on an update to RFC4741, rfc4741bis work. Further the participants supported these statements about the scope of such an undertaking: - bug fixes are to be done - clarifications can be done - no extensions (i.e. we are not doing a Netconf V2) - The work can be based on the presentation by Martin and Juergen http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf as a starting point. The WG chairs consider this to be WG consensus. If anyone on the mailing list does not agree, please speak up before Dec 3rd 2008. That is one week. We want to try and get updated charter to IESG before X-mas. The WG chairs will discuss if a charter change is needed with the AD, and if so, we will circulate draft charter text for consensus checking. Bert and Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 09:56: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 515A53A6C33; Wed, 26 Nov 2008 09:56:39 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31523A6C17 for ; Wed, 26 Nov 2008 09:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTuMB9vfHxsC for ; Wed, 26 Nov 2008 09:56:37 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 2B5613A6943 for ; Wed, 26 Nov 2008 09:56:37 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1L5Ocq-0008Fw-LM for netconf@ietf.org; Wed, 26 Nov 2008 18:56:32 +0100 Message-ID: <379908FBBB4F4797A0BDC9A7EBD8123C@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Wed, 26 Nov 2008 18:55:41 +0100 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] confirm WG consensus on potential new WG work-item: rfc4741bis X-BeenThere: netconf@ietf.org X-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 participants, At our NetConf Session at IETF73, the people in the room expressed strong support for working on an update to RFC4741, rfc4741bis work. Further the participants supported these statements about the scope of such an undertaking: - bug fixes are to be done - clarifications can be done - no extensions (i.e. we are not doing a Netconf V2) - The work can be based on the presentation by Martin and Juergen http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf as a starting point. The WG chairs consider this to be WG consensus. If anyone on the mailing list does not agree, please speak up before Dec 3rd 2008. That is one week. We want to try and get updated charter to IESG before X-mas. The WG chairs will discuss if a charter change is needed with the AD, and if so, we will circulate draft charter text for consensus checking. Bert and Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 09:58:57 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 6FD903A6C28; Wed, 26 Nov 2008 09:58:57 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D99A3A6C28 for ; Wed, 26 Nov 2008 09:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 kKwvVrJxRKDl for ; Wed, 26 Nov 2008 09:58:55 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id C06433A686A for ; Wed, 26 Nov 2008 09:58:54 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mAQHwlw25162 for ; Wed, 26 Nov 2008 17:58:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Nov 2008 12:56:49 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4176B276C@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Commons on with-defaults Draft Thread-Index: AclP8Fr2R0EJy3wDTdK4xxqKo6eszw== From: "Sharon Chisholm" To: Subject: [Netconf] Commons on with-defaults Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi As I said in Minneapolis, I believe this work is important and the current draft is a reasonable starting point. Here are the more detailed comments I promised. Major ----- 1. This capability needs to apply to all operations where it makes sense. The current text, while not strictly speaking precluding this, might be a bit misleading. It talks primarily around and . In particular, I'd like to see section 2.1 second paragraph say something more like each operation SHOULD specify how this capability affects them. 2. The with-defaults argument should go on the operation itself. . From reading section 7.1 there seems to be some sort of issue with placing it there, but I don't fully understand it. Putting the parameter on the portion will change the way the operations need to be parsed and handled by the system doesn't it? Perhaps I'll play a bit with the XSDs. 3. The behaviour really needs to be - no argument: then default behaviour of system (whether to send defaults or not) - with-defaults="true": then default values are sent - with-defaults="false": then default values are not sent Otherwise there is no way to guarantee that you don't get default-values. Medium --------- 4. In the abstract or in the introduction it should be explained that some default values are set in the Schema (XSD, YAM, RNG, etc) many others are not because they change between different implementations and potentially different versions of the machine. While in my experience there are more of the latter type than those in Schema, we probably should not go as far as saying that. The first paragraph of the Introduction (section 1) would be a good place to add this. 5. A useful concept in our internal discussions of this topic is the difference between user set of system set data. This might be better than the terminology currently in section 1.1.2. 6. I think we should be careful with the discussion of the default behaviour of the system with respect to showing defaults. I think we should acknowledge in a single section of the document what forms this might take (return them always, return them when explicitly set by the user and never return them) and then only make reference to this default behaviour as appropriate (like the behaviour we get when the with-defaults parameter is omitted). This difference and unpredictability in behaviour is because we underspecified the behaviour in RFC 4741 rather than something we need to preserve once this capability is supported. The first two paragraphs of section 2.2.1 can be replaced by a couple sentences indicating that RFC 4741 didn't specify a specific behaviour and neither does this one unless the parameter is given. 7. I'm not sure what to do with the XSD. How does this get used while validating commands? 8. In the security considerations section, we may want to add something around the fact that if you can see default values for the part of the system you have access to, than it provides insight into what values might be used (as defaults) into parts of the system or similar systems that you don't. For example, if the default port is 23434 when I learn this I might be able to use this to launch attacks. Nits and Editing ----------------- 9. The document uses agent and manager terminology instead of client and server. 10. The document uses rpc reply and rpc instead of and . 11. In section 2.1, replace "The NETCONF agent MUST also indicate it's basic behavior, whether it sends default data in the absence of any specific request from the NETCONF manager." with "The NETCONF agent MUST also indicate its basic behavior, whether it sends default data in the absence of any specific request from the NETCONF manager." 12. What are management agents? (section 2.1.1) Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 09:58:57 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 6FD903A6C28; Wed, 26 Nov 2008 09:58:57 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D99A3A6C28 for ; Wed, 26 Nov 2008 09:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 kKwvVrJxRKDl for ; Wed, 26 Nov 2008 09:58:55 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id C06433A686A for ; Wed, 26 Nov 2008 09:58:54 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mAQHwlw25162 for ; Wed, 26 Nov 2008 17:58:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Nov 2008 12:56:49 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4176B276C@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Commons on with-defaults Draft Thread-Index: AclP8Fr2R0EJy3wDTdK4xxqKo6eszw== From: "Sharon Chisholm" To: Subject: [Netconf] Commons on with-defaults Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi As I said in Minneapolis, I believe this work is important and the current draft is a reasonable starting point. Here are the more detailed comments I promised. Major ----- 1. This capability needs to apply to all operations where it makes sense. The current text, while not strictly speaking precluding this, might be a bit misleading. It talks primarily around and . In particular, I'd like to see section 2.1 second paragraph say something more like each operation SHOULD specify how this capability affects them. 2. The with-defaults argument should go on the operation itself. . From reading section 7.1 there seems to be some sort of issue with placing it there, but I don't fully understand it. Putting the parameter on the portion will change the way the operations need to be parsed and handled by the system doesn't it? Perhaps I'll play a bit with the XSDs. 3. The behaviour really needs to be - no argument: then default behaviour of system (whether to send defaults or not) - with-defaults="true": then default values are sent - with-defaults="false": then default values are not sent Otherwise there is no way to guarantee that you don't get default-values. Medium --------- 4. In the abstract or in the introduction it should be explained that some default values are set in the Schema (XSD, YAM, RNG, etc) many others are not because they change between different implementations and potentially different versions of the machine. While in my experience there are more of the latter type than those in Schema, we probably should not go as far as saying that. The first paragraph of the Introduction (section 1) would be a good place to add this. 5. A useful concept in our internal discussions of this topic is the difference between user set of system set data. This might be better than the terminology currently in section 1.1.2. 6. I think we should be careful with the discussion of the default behaviour of the system with respect to showing defaults. I think we should acknowledge in a single section of the document what forms this might take (return them always, return them when explicitly set by the user and never return them) and then only make reference to this default behaviour as appropriate (like the behaviour we get when the with-defaults parameter is omitted). This difference and unpredictability in behaviour is because we underspecified the behaviour in RFC 4741 rather than something we need to preserve once this capability is supported. The first two paragraphs of section 2.2.1 can be replaced by a couple sentences indicating that RFC 4741 didn't specify a specific behaviour and neither does this one unless the parameter is given. 7. I'm not sure what to do with the XSD. How does this get used while validating commands? 8. In the security considerations section, we may want to add something around the fact that if you can see default values for the part of the system you have access to, than it provides insight into what values might be used (as defaults) into parts of the system or similar systems that you don't. For example, if the default port is 23434 when I learn this I might be able to use this to launch attacks. Nits and Editing ----------------- 9. The document uses agent and manager terminology instead of client and server. 10. The document uses rpc reply and rpc instead of and . 11. In section 2.1, replace "The NETCONF agent MUST also indicate it's basic behavior, whether it sends default data in the absence of any specific request from the NETCONF manager." with "The NETCONF agent MUST also indicate its basic behavior, whether it sends default data in the absence of any specific request from the NETCONF manager." 12. What are management agents? (section 2.1.1) Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 10:37:41 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 7EC543A6C49; Wed, 26 Nov 2008 10:37:41 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 804AF3A6C49 for ; Wed, 26 Nov 2008 10:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.111, 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 GUK4sNv7NakG for ; Wed, 26 Nov 2008 10:37:39 -0800 (PST) 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 CE9663A6837 for ; Wed, 26 Nov 2008 10:37:39 -0800 (PST) Received: (qmail 84069 invoked from network); 26 Nov 2008 18:37:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 26 Nov 2008 18:37:35 -0000 X-YMail-OSG: s4F1or0VM1nMVHF1SNNWagWRZZdgbHv9234VxWE3QDSCiCLZWFxd33wi2VCH2AGzAmbhEOsASDLZ140pqs5lRrbsPgIlEl53NrZT8K2cyeVK4XoI9BSlXHYPTaA_A4iw15.kMfNaBEHqjYKwkp4J4Tym X-Yahoo-Newman-Property: ymail-3 Message-ID: <492D976E.3030909@netconfcentral.com> Date: Wed, 26 Nov 2008 10:37:34 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <492D6E51.6070905@netconfcentral.com> <20081126.165955.251805489.mbj@tail-f.com> In-Reply-To: <20081126.165955.251805489.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] XPath in RFC 4741 X-BeenThere: netconf@ietf.org X-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, >> >> The details on XPath filtering in 8.9.5.1 are not >> that clear. >> >> There is only a request in the example, but no reply: >> >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> >> >> >> >> >> >> >> Note the bug in the example -- the select string should start >> with an absolute-path (/top instead of top). > > Hmmm.. while I agree that the example should use "/top/...", I think > it is legal to do "top/..." - this will then be evaluated relative to > the context node which is the conceptual node. > >> Note the lack of >> namespace declarations also. > > Yes, now added to our list of things to fix. > >> Is this the correct reply? Does the node-set result get >> expanded back to root (A), or just encoded as a node-set (B)? > > IMO and IMI (in my implementation) it must be A. We want the xpath > notation to work as the subtree filter, and we want the returned > instance document to be a proper subset of the complete get-config > output. (imagine what the XSD to validate (B) would look like...) > Then this needs to be documented in 4741-bis >> What about something like select="//name"? >> >> (B) >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> fred >> barney >> eth0 >> eth1 >> >> > > With (A) you'd get: > > > > > > fred > > > barney > > > > > > eth0 > > > eth1 > > > > > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 10:37:41 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 7EC543A6C49; Wed, 26 Nov 2008 10:37:41 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 804AF3A6C49 for ; Wed, 26 Nov 2008 10:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.111, 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 GUK4sNv7NakG for ; Wed, 26 Nov 2008 10:37:39 -0800 (PST) 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 CE9663A6837 for ; Wed, 26 Nov 2008 10:37:39 -0800 (PST) Received: (qmail 84069 invoked from network); 26 Nov 2008 18:37:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 26 Nov 2008 18:37:35 -0000 X-YMail-OSG: s4F1or0VM1nMVHF1SNNWagWRZZdgbHv9234VxWE3QDSCiCLZWFxd33wi2VCH2AGzAmbhEOsASDLZ140pqs5lRrbsPgIlEl53NrZT8K2cyeVK4XoI9BSlXHYPTaA_A4iw15.kMfNaBEHqjYKwkp4J4Tym X-Yahoo-Newman-Property: ymail-3 Message-ID: <492D976E.3030909@netconfcentral.com> Date: Wed, 26 Nov 2008 10:37:34 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <492D6E51.6070905@netconfcentral.com> <20081126.165955.251805489.mbj@tail-f.com> In-Reply-To: <20081126.165955.251805489.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] XPath in RFC 4741 X-BeenThere: netconf@ietf.org X-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, >> >> The details on XPath filtering in 8.9.5.1 are not >> that clear. >> >> There is only a request in the example, but no reply: >> >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> >> >> >> >> >> >> >> Note the bug in the example -- the select string should start >> with an absolute-path (/top instead of top). > > Hmmm.. while I agree that the example should use "/top/...", I think > it is legal to do "top/..." - this will then be evaluated relative to > the context node which is the conceptual node. > >> Note the lack of >> namespace declarations also. > > Yes, now added to our list of things to fix. > >> Is this the correct reply? Does the node-set result get >> expanded back to root (A), or just encoded as a node-set (B)? > > IMO and IMI (in my implementation) it must be A. We want the xpath > notation to work as the subtree filter, and we want the returned > instance document to be a proper subset of the complete get-config > output. (imagine what the XSD to validate (B) would look like...) > Then this needs to be documented in 4741-bis >> What about something like select="//name"? >> >> (B) >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> fred >> barney >> eth0 >> eth1 >> >> > > With (A) you'd get: > > > > > > fred > > > barney > > > > > > eth0 > > > eth1 > > > > > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 11:27:36 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 4B7F63A6C71; Wed, 26 Nov 2008 11:27:36 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67A528C14E for ; Wed, 26 Nov 2008 11:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 ClIymxkzsALY for ; Wed, 26 Nov 2008 11:27:34 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id BD17C3A6C6D for ; Wed, 26 Nov 2008 11:27:33 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mAQJRRj15864; Wed, 26 Nov 2008 19:27:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Nov 2008 14:27:11 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4176B2979@zcarhxm2.corp.nortel.com> In-Reply-To: <4D7EEB1103FA450A907208A7CCFACC4E@BertLaptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] confirm WG consensus on potential new WG work-item:notification Thread-Index: AclP8FUCLVCKcFw/QKqMwSMEthuIbwADCS8w References: <4D7EEB1103FA450A907208A7CCFACC4E@BertLaptop> From: "Sharon Chisholm" To: "Bert Wijnen (IETF)" , "Netconf" Subject: Re: [Netconf] confirm WG consensus on potential new WG work-item:notification X-BeenThere: netconf@ietf.org X-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 believe how several people expressed things was a header plus a small set (1-3) notifications that we really need. As indicated, I'm willing to work with the editor to extract out the appropriate portions of the not-content individual submission that meets this agreed to scope. First though, we need to agree on what the small set of notification would be. I'd vote for configuration change events and software upgrade notifications. Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) Sent: Wednesday, November 26, 2008 12:56 PM To: Netconf Subject: [Netconf] confirm WG consensus on potential new WG work-item:notification WG participants, At our NetConf Session at IETF73, the people in the room expressed strong support for the following statements: - We do not want to define extensive Notification content NOW - We just want to define content for notifications that we URGENTLY need now (within the next year). That is one or two notifications - Less urgent notification content we can define once the NETMOD results become available The WG chairs consider this to be WG consensus. If anyone on the mailing list does not agree, please speak up before Dec 3rd 2008. That is one week. We want to try and get updated charter to IESG before X-mas. The WG chairs do not want to consider draft-chisholm-netconf-not-content-00.txt as a starting point. The reason being that it wants to do much more than the minimal approach that is expressed above. The WG chairs will propose/draft new charter text that we will circulate for consensus checking. Once we have such a draft text, we will also call for volunteers to become editors of the document. Bert and Mehmet _______________________________________________ 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 Wed Nov 26 11:27:36 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 4B7F63A6C71; Wed, 26 Nov 2008 11:27:36 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67A528C14E for ; Wed, 26 Nov 2008 11:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 ClIymxkzsALY for ; Wed, 26 Nov 2008 11:27:34 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id BD17C3A6C6D for ; Wed, 26 Nov 2008 11:27:33 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mAQJRRj15864; Wed, 26 Nov 2008 19:27:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Nov 2008 14:27:11 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4176B2979@zcarhxm2.corp.nortel.com> In-Reply-To: <4D7EEB1103FA450A907208A7CCFACC4E@BertLaptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] confirm WG consensus on potential new WG work-item:notification Thread-Index: AclP8FUCLVCKcFw/QKqMwSMEthuIbwADCS8w References: <4D7EEB1103FA450A907208A7CCFACC4E@BertLaptop> From: "Sharon Chisholm" To: "Bert Wijnen (IETF)" , "Netconf" Subject: Re: [Netconf] confirm WG consensus on potential new WG work-item:notification X-BeenThere: netconf@ietf.org X-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 believe how several people expressed things was a header plus a small set (1-3) notifications that we really need. As indicated, I'm willing to work with the editor to extract out the appropriate portions of the not-content individual submission that meets this agreed to scope. First though, we need to agree on what the small set of notification would be. I'd vote for configuration change events and software upgrade notifications. Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) Sent: Wednesday, November 26, 2008 12:56 PM To: Netconf Subject: [Netconf] confirm WG consensus on potential new WG work-item:notification WG participants, At our NetConf Session at IETF73, the people in the room expressed strong support for the following statements: - We do not want to define extensive Notification content NOW - We just want to define content for notifications that we URGENTLY need now (within the next year). That is one or two notifications - Less urgent notification content we can define once the NETMOD results become available The WG chairs consider this to be WG consensus. If anyone on the mailing list does not agree, please speak up before Dec 3rd 2008. That is one week. We want to try and get updated charter to IESG before X-mas. The WG chairs do not want to consider draft-chisholm-netconf-not-content-00.txt as a starting point. The reason being that it wants to do much more than the minimal approach that is expressed above. The WG chairs will propose/draft new charter text that we will circulate for consensus checking. Once we have such a draft text, we will also call for volunteers to become editors of the document. Bert and Mehmet _______________________________________________ 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 Wed Nov 26 12:32: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 E7FA63A6835; Wed, 26 Nov 2008 12:32:30 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F773A67AF for ; Wed, 26 Nov 2008 12:32:28 -0800 (PST) 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 kIQUPo-TzRi6 for ; Wed, 26 Nov 2008 12:32:28 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EF5493A6835 for ; Wed, 26 Nov 2008 12:32:27 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9628776C310; Wed, 26 Nov 2008 21:32:23 +0100 (CET) Date: Wed, 26 Nov 2008 21:32:23 +0100 (CET) Message-Id: <20081126.213223.33941354.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <492D837C.3020204@netconfcentral.com> References: <492D6E51.6070905@netconfcentral.com> <492D752C.5050605@s3group.com> <492D837C.3020204@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] XPath in RFC 4741 X-BeenThere: netconf@ietf.org X-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: > Where does it say in 4741 that XPath filtered output > looks the same as subtree-filtered output? It doesn't but note that you use the term "filtered output". There are two ways to *filter* the output. Subtree and XPath. I think the result should look the same regardless of which filter mechanism was used. [I know that this exact issue has been discussed on the ML, but I could not find a reference right now.] > RFC 4741 seems to say "use XPath and do what XPath > says to do". That was the intent of the WG at the > time it was written. > > It seems to me that XPath 1.0 does not return all > the ancestor nodes in a node-set result, but rather > the requested nodes. Absolutely. Note that it returns the *nodes* in the tree only. XPath itself does not - by design - talk about what to do with these nodes. That it is up to the application which uses XPath to define. The application in our case is NETCONF. [...] > XPath is intended to be used in some application context, > where something is being done to the result nodes. So you say the same thing as I did above. > In this hypothetical application, it makes much more sense to > do what XPath says instead of making up rules about returning > all the ancestor nodes. But XPath doesn't say anything about what to do with these nodes! If you use XPath filters to search the data store for matching instances, you definitely need the entire path including key values. For example: # netconf-console --get-config \ --xpath '/aaa/authentication/users/user[gid="100"]'/gid admin 100 oper 100 This is much easier to do in scripts that constructing the equivalent subtree filter. And XPath can of course do much more than subtree filters anyway. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 12:32: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 E7FA63A6835; Wed, 26 Nov 2008 12:32:30 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F773A67AF for ; Wed, 26 Nov 2008 12:32:28 -0800 (PST) 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 kIQUPo-TzRi6 for ; Wed, 26 Nov 2008 12:32:28 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EF5493A6835 for ; Wed, 26 Nov 2008 12:32:27 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9628776C310; Wed, 26 Nov 2008 21:32:23 +0100 (CET) Date: Wed, 26 Nov 2008 21:32:23 +0100 (CET) Message-Id: <20081126.213223.33941354.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <492D837C.3020204@netconfcentral.com> References: <492D6E51.6070905@netconfcentral.com> <492D752C.5050605@s3group.com> <492D837C.3020204@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] XPath in RFC 4741 X-BeenThere: netconf@ietf.org X-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: > Where does it say in 4741 that XPath filtered output > looks the same as subtree-filtered output? It doesn't but note that you use the term "filtered output". There are two ways to *filter* the output. Subtree and XPath. I think the result should look the same regardless of which filter mechanism was used. [I know that this exact issue has been discussed on the ML, but I could not find a reference right now.] > RFC 4741 seems to say "use XPath and do what XPath > says to do". That was the intent of the WG at the > time it was written. > > It seems to me that XPath 1.0 does not return all > the ancestor nodes in a node-set result, but rather > the requested nodes. Absolutely. Note that it returns the *nodes* in the tree only. XPath itself does not - by design - talk about what to do with these nodes. That it is up to the application which uses XPath to define. The application in our case is NETCONF. [...] > XPath is intended to be used in some application context, > where something is being done to the result nodes. So you say the same thing as I did above. > In this hypothetical application, it makes much more sense to > do what XPath says instead of making up rules about returning > all the ancestor nodes. But XPath doesn't say anything about what to do with these nodes! If you use XPath filters to search the data store for matching instances, you definitely need the entire path including key values. For example: # netconf-console --get-config \ --xpath '/aaa/authentication/users/user[gid="100"]'/gid admin 100 oper 100 This is much easier to do in scripts that constructing the equivalent subtree filter. And XPath can of course do much more than subtree filters anyway. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 13:56: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 9F7C93A6C8D; Wed, 26 Nov 2008 13:56:32 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF3543A6C8D for ; Wed, 26 Nov 2008 13:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.337, 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 7rDVyBChiXUu for ; Wed, 26 Nov 2008 13:56:29 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B388F3A6A15 for ; Wed, 26 Nov 2008 13:56:28 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D79EC0063; Wed, 26 Nov 2008 22:56:25 +0100 (CET) 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 pw2zQgvhHhUk; Wed, 26 Nov 2008 22:56:20 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1100BC0057; Wed, 26 Nov 2008 22:56:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CF16F88480B; Wed, 26 Nov 2008 22:56:18 +0100 (CET) Date: Wed, 26 Nov 2008 22:56:18 +0100 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20081126215618.GA6221@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , Netconf References: <4D7EEB1103FA450A907208A7CCFACC4E@BertLaptop> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4D7EEB1103FA450A907208A7CCFACC4E@BertLaptop> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Netconf Subject: Re: [Netconf] confirm WG consensus on potential new WG work-item: notification 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, Nov 26, 2008 at 06:56:09PM +0100, Bert Wijnen (IETF) wrote: > WG participants, > > At our NetConf Session at IETF73, the people in the room expressed strong > support for the following statements: > > - We do not want to define extensive Notification content NOW > - We just want to define content for notifications that we URGENTLY > need now (within the next year). That is one or two notifications > - Less urgent notification content we can define once the NETMOD > results become available > > The WG chairs consider this to be WG consensus. If anyone on the mailing > list does not agree, please speak up before Dec 3rd 2008. That is one week. > We want to try and get updated charter to IESG before X-mas. My problem is that it remains unclear to me what the URGENTLY needed notifications are - neither the ID nor the Minneapolis audio stream I listened to answered that question. If something gets added to the charter, then I think it must be more concrete than "URGENTLY needed notifications". Perhaps someone can post a more concrete proposal? /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 Nov 26 13:56: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 9F7C93A6C8D; Wed, 26 Nov 2008 13:56:32 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF3543A6C8D for ; Wed, 26 Nov 2008 13:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.337, 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 7rDVyBChiXUu for ; Wed, 26 Nov 2008 13:56:29 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B388F3A6A15 for ; Wed, 26 Nov 2008 13:56:28 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D79EC0063; Wed, 26 Nov 2008 22:56:25 +0100 (CET) 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 pw2zQgvhHhUk; Wed, 26 Nov 2008 22:56:20 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1100BC0057; Wed, 26 Nov 2008 22:56:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CF16F88480B; Wed, 26 Nov 2008 22:56:18 +0100 (CET) Date: Wed, 26 Nov 2008 22:56:18 +0100 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20081126215618.GA6221@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , Netconf References: <4D7EEB1103FA450A907208A7CCFACC4E@BertLaptop> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4D7EEB1103FA450A907208A7CCFACC4E@BertLaptop> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Netconf Subject: Re: [Netconf] confirm WG consensus on potential new WG work-item: notification 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, Nov 26, 2008 at 06:56:09PM +0100, Bert Wijnen (IETF) wrote: > WG participants, > > At our NetConf Session at IETF73, the people in the room expressed strong > support for the following statements: > > - We do not want to define extensive Notification content NOW > - We just want to define content for notifications that we URGENTLY > need now (within the next year). That is one or two notifications > - Less urgent notification content we can define once the NETMOD > results become available > > The WG chairs consider this to be WG consensus. If anyone on the mailing > list does not agree, please speak up before Dec 3rd 2008. That is one week. > We want to try and get updated charter to IESG before X-mas. My problem is that it remains unclear to me what the URGENTLY needed notifications are - neither the ID nor the Minneapolis audio stream I listened to answered that question. If something gets added to the charter, then I think it must be more concrete than "URGENTLY needed notifications". Perhaps someone can post a more concrete proposal? /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 Nov 26 14:00: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 43ADB3A69BC; Wed, 26 Nov 2008 14:00:40 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16DB83A69BC for ; Wed, 26 Nov 2008 14:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.281, 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 CxrtgtTWH4BT for ; Wed, 26 Nov 2008 14:00:38 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 51B6C3A6813 for ; Wed, 26 Nov 2008 14:00:38 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 82386C005D; Wed, 26 Nov 2008 23:00:35 +0100 (CET) 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 9GqZdKFxQ40L; Wed, 26 Nov 2008 23:00:30 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 421B5C0057; Wed, 26 Nov 2008 23:00:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 27F96884865; Wed, 26 Nov 2008 23:00:29 +0100 (CET) Date: Wed, 26 Nov 2008 23:00:29 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Message-ID: <20081126220029.GB6221@elstar.local> Mail-Followup-To: Sharon Chisholm , netconf@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B4176B276C@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4176B276C@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Commons on with-defaults Draft 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, Nov 26, 2008 at 12:56:49PM -0500, Sharon Chisholm wrote: > 2. The with-defaults argument should go on the operation itself. > . From > reading section 7.1 there seems to be some sort of issue with placing it > there, but I don't fully understand it. Putting the parameter on the > portion will change the way the operations need to be parsed and > handled by the system doesn't it? Perhaps I'll play a bit with the XSDs. I agree - I have been pretty surprised to see with-defaults on the RPC layer and not the operations layer - looks like a layer violation to me. /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 Nov 26 14:00: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 43ADB3A69BC; Wed, 26 Nov 2008 14:00:40 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16DB83A69BC for ; Wed, 26 Nov 2008 14:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.281, 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 CxrtgtTWH4BT for ; Wed, 26 Nov 2008 14:00:38 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 51B6C3A6813 for ; Wed, 26 Nov 2008 14:00:38 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 82386C005D; Wed, 26 Nov 2008 23:00:35 +0100 (CET) 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 9GqZdKFxQ40L; Wed, 26 Nov 2008 23:00:30 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 421B5C0057; Wed, 26 Nov 2008 23:00:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 27F96884865; Wed, 26 Nov 2008 23:00:29 +0100 (CET) Date: Wed, 26 Nov 2008 23:00:29 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Message-ID: <20081126220029.GB6221@elstar.local> Mail-Followup-To: Sharon Chisholm , netconf@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B4176B276C@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4176B276C@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Commons on with-defaults Draft 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, Nov 26, 2008 at 12:56:49PM -0500, Sharon Chisholm wrote: > 2. The with-defaults argument should go on the operation itself. > . From > reading section 7.1 there seems to be some sort of issue with placing it > there, but I don't fully understand it. Putting the parameter on the > portion will change the way the operations need to be parsed and > handled by the system doesn't it? Perhaps I'll play a bit with the XSDs. I agree - I have been pretty surprised to see with-defaults on the RPC layer and not the operations layer - looks like a layer violation to me. /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 Nov 26 14:04: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 2CB3A28C227; Wed, 26 Nov 2008 14:04:31 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3CD28C227 for ; Wed, 26 Nov 2008 14:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.272, 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 dtrC5Tsq-5ib for ; Wed, 26 Nov 2008 14:04:29 -0800 (PST) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id 1B8E628C1F8 for ; Wed, 26 Nov 2008 14:04:29 -0800 (PST) Received: (qmail 67843 invoked from network); 26 Nov 2008 22:04:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 26 Nov 2008 22:04:24 -0000 X-YMail-OSG: cl4b8PIVM1lZH5htRQxDz72rEYLnsgmtZ35odxcp33i7S8et21uWjyWiA4_retH5SIp4gShXGN7P9vxyjTODTiz5CrtREtsVj_cslmUyPyEuBVdxVUWDGW8humPkC0iRjV4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <492DC7E6.9050001@netconfcentral.com> Date: Wed, 26 Nov 2008 14:04:22 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Sharon Chisholm , netconf@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B4176B276C@zcarhxm2.corp.nortel.com> <20081126220029.GB6221@elstar.local> In-Reply-To: <20081126220029.GB6221@elstar.local> Subject: Re: [Netconf] Commons on with-defaults Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Wed, Nov 26, 2008 at 12:56:49PM -0500, Sharon Chisholm wrote: > >> 2. The with-defaults argument should go on the operation itself. >> . From >> reading section 7.1 there seems to be some sort of issue with placing it >> there, but I don't fully understand it. Putting the parameter on the >> portion will change the way the operations need to be parsed and >> handled by the system doesn't it? Perhaps I'll play a bit with the XSDs. > > I agree - I have been pretty surprised to see with-defaults on the RPC > layer and not the operations layer - looks like a layer violation to > me. > The reason for this is that the element already has to accept any XML attribute and return it unchanged. It was the path of least resistance, especially for a vendor extension. For a standard, normal element-based parameters would be the most YANG-ish thing to do. > /js > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 14:04: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 2CB3A28C227; Wed, 26 Nov 2008 14:04:31 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3CD28C227 for ; Wed, 26 Nov 2008 14:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.272, 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 dtrC5Tsq-5ib for ; Wed, 26 Nov 2008 14:04:29 -0800 (PST) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id 1B8E628C1F8 for ; Wed, 26 Nov 2008 14:04:29 -0800 (PST) Received: (qmail 67843 invoked from network); 26 Nov 2008 22:04:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 26 Nov 2008 22:04:24 -0000 X-YMail-OSG: cl4b8PIVM1lZH5htRQxDz72rEYLnsgmtZ35odxcp33i7S8et21uWjyWiA4_retH5SIp4gShXGN7P9vxyjTODTiz5CrtREtsVj_cslmUyPyEuBVdxVUWDGW8humPkC0iRjV4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <492DC7E6.9050001@netconfcentral.com> Date: Wed, 26 Nov 2008 14:04:22 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Sharon Chisholm , netconf@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B4176B276C@zcarhxm2.corp.nortel.com> <20081126220029.GB6221@elstar.local> In-Reply-To: <20081126220029.GB6221@elstar.local> Subject: Re: [Netconf] Commons on with-defaults Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Wed, Nov 26, 2008 at 12:56:49PM -0500, Sharon Chisholm wrote: > >> 2. The with-defaults argument should go on the operation itself. >> . From >> reading section 7.1 there seems to be some sort of issue with placing it >> there, but I don't fully understand it. Putting the parameter on the >> portion will change the way the operations need to be parsed and >> handled by the system doesn't it? Perhaps I'll play a bit with the XSDs. > > I agree - I have been pretty surprised to see with-defaults on the RPC > layer and not the operations layer - looks like a layer violation to > me. > The reason for this is that the element already has to accept any XML attribute and return it unchanged. It was the path of least resistance, especially for a vendor extension. For a standard, normal element-based parameters would be the most YANG-ish thing to do. > /js > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 14:12: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 69BD73A69EA; Wed, 26 Nov 2008 14:12:31 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09FFA3A69EA for ; Wed, 26 Nov 2008 14:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.092, 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 ugia-mxeym7i for ; Wed, 26 Nov 2008 14:12:29 -0800 (PST) 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 460B83A6813 for ; Wed, 26 Nov 2008 14:12:29 -0800 (PST) Received: (qmail 92533 invoked from network); 26 Nov 2008 22:12:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 26 Nov 2008 22:12:24 -0000 X-YMail-OSG: qhS200IVM1m.21hCs._sN0xYU3X4PiaVHd4bTbF3_KPM0tOEOF7RdDbwrTJxjytxvgge6oGapiBksdwhabkyx5KIg4_Ma9n60xwOxdnlkFvAnHmb.ny_y0h.aNHcysV7U2sSRsGF30BQ09AM_aNtyhAi X-Yahoo-Newman-Property: ymail-3 Message-ID: <492DC9C7.3020402@netconfcentral.com> Date: Wed, 26 Nov 2008 14:12:23 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <492D6E51.6070905@netconfcentral.com> <492D752C.5050605@s3group.com> <492D837C.3020204@netconfcentral.com> <20081126.213223.33941354.mbj@tail-f.com> In-Reply-To: <20081126.213223.33941354.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] XPath in RFC 4741 X-BeenThere: netconf@ietf.org X-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: >> Where does it say in 4741 that XPath filtered output >> looks the same as subtree-filtered output? > > It doesn't but note that you use the term "filtered output". There > are two ways to *filter* the output. Subtree and XPath. I think the > result should look the same regardless of which filter mechanism was used. > > [I know that this exact issue has been discussed on the ML, but I > could not find a reference right now.] > >> RFC 4741 seems to say "use XPath and do what XPath >> says to do". That was the intent of the WG at the >> time it was written. >> >> It seems to me that XPath 1.0 does not return all >> the ancestor nodes in a node-set result, but rather >> the requested nodes. > > Absolutely. Note that it returns the *nodes* in the tree only. XPath > itself does not - by design - talk about what to do with these nodes. > That it is up to the application which uses XPath to define. The > application in our case is NETCONF. > > [...] > >> XPath is intended to be used in some application context, >> where something is being done to the result nodes. > > So you say the same thing as I did above. > >> In this hypothetical apFrom netconf-bounces@ietf.org Wed Nov 26 14:12: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 69BD73A69EA; Wed, 26 Nov 2008 14:12:31 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09FFA3A69EA for ; Wed, 26 Nov 2008 14:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.092, 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 ugia-mxeym7i for ; Wed, 26 Nov 2008 14:12:29 -0800 (PST) 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 460B83A6813 for ; Wed, 26 Nov 2008 14:12:29 -0800 (PST) Received: (qmail 92533 invoked from network); 26 Nov 2008 22:12:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 26 Nov 2008 22:12:24 -0000 X-YMail-OSG: qhS200IVM1m.21hCs._sN0xYU3X4PiaVHd4bTbF3_KPM0tOEOF7RdDbwrTJxjytxvgge6oGapiBksdwhabkyx5KIg4_Ma9n60xwOxdnlkFvAnHmb.ny_y0h.aNHcysV7U2sSRsGF30BQ09AM_aNtyhAi X-Yahoo-Newman-Property: ymail-3 Message-ID: <492DC9C7.3020402@netconfcentral.com> Date: Wed, 26 Nov 2008 14:12:23 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <492D6E51.6070905@netconfcentral.com> <492D752C.5050605@s3group.com> <492D837C.3020204@netconfcentral.com> <20081126.213223.33941354.mbj@tail-f.com> In-Reply-To: <20081126.213223.33941354.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] XPath in RFC 4741 X-BeenThere: netconf@ietf.org X-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: >> Where does it say in 4741 that XPath filtered output >> looks the same as subtree-filtered output? > > It doesn't but note that you use the term "filtered output". There > are two ways to *filter* the output. Subtree and XPath. I think the > result should look the same regardless of which filter mechanism was used. > > [I know that this exact issue has been discussed on the ML, but I > could not find a reference right now.] > >> RFC 4741 seems to say "use XPath and do what XPath >> says to do". That was the intent of the WG at the >> time it was written. >> >> It seems to me that XPath 1.0 does not return all >> the ancestor nodes in a node-set result, but rather >> the requested nodes. > > Absolutely. Note that it returns the *nodes* in the tree only. XPath > itself does not - by design - talk about what to do with these nodes. > That it is up to the application which uses XPath to define. The > application in our case is NETCONF. > > [...] > >> XPath is intended to be used in some application context, >> where something is being done to the result nodes. > > So you say the same thing as I did above. > >> In this hypothetiplication, it makes much more sense to >> do what XPath says instead of making up rules about returning >> all the ancestor nodes. > > But XPath doesn't say anything about what to do with these nodes! > Right. So NETCONF has to say what to do with them for and . All ancestor nodes need to be returned, and for all ancestor-or-self nodes that represent a list with a key, all key leafs must be present as child nodes of each list. > If you use XPath filters to search the data store for matching > instances, you definitely need the entire path including key values. > For example: > > # netconf-console --get-config \ > --xpath '/aaa/authentication/users/user[gid="100"]'/gid > There are searches that the bare node-set would be fine, since the manager knows what it asked for. There are lots of searches (like your example) that can have multiple hits, so the path to root is better. > > > > > > > > admin > 100 > > > oper > 100 > > > > > > > > > This is much easier to do in scripts that constructing the equivalent > subtree filter. And XPath can of course do much more than subtree > filters anyway. > This is fine -- just document it in the NETCONF standard. This is what I planned to implement until reading the XPath spec several times, which made me think I should follow those rules instead. > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf cal application, it makes much more sense to >> do what XPath says instead of making up rules about returning >> all the ancestor nodes. > > But XPath doesn't say anything about what to do with these nodes! > Right. So NETCONF has to say what to do with them for and . All ancestor nodes need to be returned, and for all ancestor-or-self nodes that represent a list with a key, all key leafs must be present as child nodes of each list. > If you use XPath filters to search the data store for matching > instances, you definitely need the entire path including key values. > For example: > > # netconf-console --get-config \ > --xpath '/aaa/authentication/users/user[gid="100"]'/gid > There are searches that the bare node-set would be fine, since the manager knows what it asked for. There are lots of searches (like your example) that can have multiple hits, so the path to root is better. > > > > > > > > admin > 100 > > > oper > 100 > > > > > > > > > This is much easier to do in scripts that constructing the equivalent > subtree filter. And XPath can of course do much more than subtree > filters anyway. > This is fine -- just document it in the NETCONF standard. This is what I planned to implement until reading the XPath spec several times, which made me think I should follow those rules instead. > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 14:18: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 5B9A728C259; Wed, 26 Nov 2008 14:18:15 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCD9B28C24F for ; Wed, 26 Nov 2008 14:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.912 X-Spam-Level: X-Spam-Status: No, score=0.912 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_20=-0.74, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22YwQ1TKYvOr for ; Wed, 26 Nov 2008 14:18:13 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id D75E028C25B for ; Wed, 26 Nov 2008 14:18:12 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1L5Shz-00058i-LD; Wed, 26 Nov 2008 23:18:07 +0100 Message-ID: From: "Bert Wijnen \(IETF\)" To: References: <4D7EEB1103FA450A907208A7CCFACC4E@BertLaptop> <20081126215618.GA6221@elstar.local> In-Reply-To: <20081126215618.GA6221@elstar.local> Date: Wed, 26 Nov 2008 23:17:45 +0100 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 Subject: Re: [Netconf] confirm WG consensus on potential new WG work-item:notification X-BeenThere: netconf@ietf.org X-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="===============1825763862==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1825763862== Content-Type: multipart/alternative; boundary="----=_NextPart_000_02FD_01C9501D.30CC0340" This is a multi-part message in MIME format. ------=_NextPart_000_02FD_01C9501D.30CC0340 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Juergen wrote: My problem is that it remains unclear to me what the URGENTLY needed notifications are - neither the ID nor the Minneapolis audio stream I listened to answered that question. If something gets added to the charter, then I think it must be more concrete than "URGENTLY needed notifications". Perhaps someone can post a more concrete proposal? Sharon has mentioned 2 to the list recently (Iirc) and I have heard = that Phil has 2 in mind as well. Maybe Phil can post his list. Bert ------=_NextPart_000_02FD_01C9501D.30CC0340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Juergen wrote:
 
  My problem is that it remains unclear to me what the = URGENTLY=20 needed
  notifications are - neither the ID nor the Minneapolis = audio=20 stream I
  listened to answered that question. If something gets = added=20 to the
  charter, then I think it must be more concrete than = "URGENTLY=20 needed
  notifications". Perhaps someone can post a more = concrete=20 proposal?
 
Sharon has mentioned 2  to the list recently = (Iirc) and I=20 have heard that Phil has
2 in mind as well. Maybe Phil can post his = list.
 
Bert
------=_NextPart_000_02FD_01C9501D.30CC0340-- --===============1825763862== 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 --===============1825763862==-- From netconf-bounces@ietf.org Wed Nov 26 14:18: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 5B9A728C259; Wed, 26 Nov 2008 14:18:15 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCD9B28C24F for ; Wed, 26 Nov 2008 14:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.912 X-Spam-Level: X-Spam-Status: No, score=0.912 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_20=-0.74, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22YwQ1TKYvOr for ; Wed, 26 Nov 2008 14:18:13 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id D75E028C25B for ; Wed, 26 Nov 2008 14:18:12 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1L5Shz-00058i-LD; Wed, 26 Nov 2008 23:18:07 +0100 Message-ID: From: "Bert Wijnen \(IETF\)" To: References: <4D7EEB1103FA450A907208A7CCFACC4E@BertLaptop> <20081126215618.GA6221@elstar.local> In-Reply-To: <20081126215618.GA6221@elstar.local> Date: Wed, 26 Nov 2008 23:17:45 +0100 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 Subject: Re: [Netconf] confirm WG consensus on potential new WG work-item:notification X-BeenThere: netconf@ietf.org X-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="===============1825763862==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1825763862== Content-Type: multipart/alternative; boundary="----=_NextPart_000_02FD_01C9501D.30CC0340" This is a multi-part message in MIME format. ------=_NextPart_000_02FD_01C9501D.30CC0340 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Juergen wrote: My problem is that it remains unclear to me what the URGENTLY needed notifications are - neither the ID nor the Minneapolis audio stream I listened to answered that question. If something gets added to the charter, then I think it must be more concrete than "URGENTLY needed notifications". Perhaps someone can post a more concrete proposal? Sharon has mentioned 2 to the list recently (Iirc) and I have heard = that Phil has 2 in mind as well. Maybe Phil can post his list. Bert ------=_NextPart_000_02FD_01C9501D.30CC0340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Juergen wrote:
 
  My problem is that it remains unclear to me what the = URGENTLY=20 needed
  notifications are - neither the ID nor the Minneapolis = audio=20 stream I
  listened to answered that question. If something gets = added=20 to the
  charter, then I think it must be more concrete than = "URGENTLY=20 needed
  notifications". Perhaps someone can post a more = concrete=20 proposal?
 
Sharon has mentioned 2  to the list recently = (Iirc) and I=20 have heard that Phil has
2 in mind as well. Maybe Phil can post his = list.
 
Bert
------=_NextPart_000_02FD_01C9501D.30CC0340-- --===============1825763862== 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 --===============1825763862==-- From netconf-bounces@ietf.org Wed Nov 26 14:34: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 917D428C254; Wed, 26 Nov 2008 14:34:13 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 574CE28C24C for ; Wed, 26 Nov 2008 14:34:13 -0800 (PST) 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=[AWL=-0.000, 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 Rt9eKypwrDHY for ; Wed, 26 Nov 2008 14:34:12 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2842B3A6914 for ; Wed, 26 Nov 2008 14:34:11 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id DC45676C310; Wed, 26 Nov 2008 23:34:07 +0100 (CET) Date: Wed, 26 Nov 2008 23:34:07 +0100 (CET) Message-Id: <20081126.233407.202709362.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <492DC7E6.9050001@netconfcentral.com> References: <713043CE8B8E1348AF3C546DBE02C1B4176B276C@zcarhxm2.corp.nortel.com> <20081126220029.GB6221@elstar.local> <492DC7E6.9050001@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Commons on with-defaults Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: > Juergen Schoenwaelder wrote: > > On Wed, Nov 26, 2008 at 12:56:49PM -0500, Sharon Chisholm wrote: > > > >> 2. The with-defaults argument should go on the operation itself. > >> . From > >> reading section 7.1 there seems to be some sort of issue with placing it > >> there, but I don't fully understand it. Putting the parameter on the > >> portion will change the way the operations need to be parsed and > >> handled by the system doesn't it? Perhaps I'll play a bit with the XSDs. > > I agree - I have been pretty surprised to see with-defaults on the RPC > > layer and not the operations layer - looks like a layer violation to > > me. > > > > The reason for this is that the element already has > to accept any XML attribute and return it unchanged. > It was the path of least resistance, especially for > a vendor extension. > > For a standard, normal element-based parameters would > be the most YANG-ish thing to do. I agree. The problem is that the XSD in 4741 is not an open schema in that it does not allow unknown elements or attributes (with the exception of ). I think that this was not the intention with the spec, and that it should be clarified in 4741bis. I think the intention was that capabilities could add parameters to the operations, even though not explicitly allowed by the XSD. We can either make the XSD explicitly open (that'll be ugly though - XSD 1.1 anyone ;-), or we can just state this in text. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 14:34: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 917D428C254; Wed, 26 Nov 2008 14:34:13 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 574CE28C24C for ; Wed, 26 Nov 2008 14:34:13 -0800 (PST) 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=[AWL=-0.000, 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 Rt9eKypwrDHY for ; Wed, 26 Nov 2008 14:34:12 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2842B3A6914 for ; Wed, 26 Nov 2008 14:34:11 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id DC45676C310; Wed, 26 Nov 2008 23:34:07 +0100 (CET) Date: Wed, 26 Nov 2008 23:34:07 +0100 (CET) Message-Id: <20081126.233407.202709362.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <492DC7E6.9050001@netconfcentral.com> References: <713043CE8B8E1348AF3C546DBE02C1B4176B276C@zcarhxm2.corp.nortel.com> <20081126220029.GB6221@elstar.local> <492DC7E6.9050001@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Commons on with-defaults Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: > Juergen Schoenwaelder wrote: > > On Wed, Nov 26, 2008 at 12:56:49PM -0500, Sharon Chisholm wrote: > > > >> 2. The with-defaults argument should go on the operation itself. > >> . From > >> reading section 7.1 there seems to be some sort of issue with placing it > >> there, but I don't fully understand it. Putting the parameter on the > >> portion will change the way the operations need to be parsed and > >> handled by the system doesn't it? Perhaps I'll play a bit with the XSDs. > > I agree - I have been pretty surprised to see with-defaults on the RPC > > layer and not the operations layer - looks like a layer violation to > > me. > > > > The reason for this is that the element already has > to accept any XML attribute and return it unchanged. > It was the path of least resistance, especially for > a vendor extension. > > For a standard, normal element-based parameters would > be the most YANG-ish thing to do. I agree. The problem is that the XSD in 4741 is not an open schema in that it does not allow unknown elements or attributes (with the exception of ). I think that this was not the intention with the spec, and that it should be clarified in 4741bis. I think the intention was that capabilities could add parameters to the operations, even though not explicitly allowed by the XSD. We can either make the XSD explicitly open (that'll be ugly though - XSD 1.1 anyone ;-), or we can just state this in text. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 14:37: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 C69063A6A22; Wed, 26 Nov 2008 14:37:06 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2EEE3A6A22 for ; Wed, 26 Nov 2008 14:37:05 -0800 (PST) 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 DCV1my5q611A for ; Wed, 26 Nov 2008 14:37:05 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 25B303A6914 for ; Wed, 26 Nov 2008 14:37:05 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id E1B7176C508; Wed, 26 Nov 2008 23:37:01 +0100 (CET) Date: Wed, 26 Nov 2008 23:36:58 +0100 (CET) Message-Id: <20081126.233658.220882635.mbj@tail-f.com> To: schishol@nortel.com From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4176B276C@zcarhxm2.corp.nortel.com> References: <713043CE8B8E1348AF3C546DBE02C1B4176B276C@zcarhxm2.corp.nortel.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Commons on with-defaults Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Sharon Chisholm" wrote: > 3. The behaviour really needs to be > - no argument: then default behaviour of system (whether to send > defaults or not) > - with-defaults="true": then default values are sent > - with-defaults="false": then default values are not sent > Otherwise there is no way to guarantee that you don't get > default-values. +1 And we should allow for devices which cannot distinguish between defaults and other values to not have to support with-defaults="false". I think it's better that they don't implement it, rather than fake it. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 14:37: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 C69063A6A22; Wed, 26 Nov 2008 14:37:06 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2EEE3A6A22 for ; Wed, 26 Nov 2008 14:37:05 -0800 (PST) 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 DCV1my5q611A for ; Wed, 26 Nov 2008 14:37:05 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 25B303A6914 for ; Wed, 26 Nov 2008 14:37:05 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id E1B7176C508; Wed, 26 Nov 2008 23:37:01 +0100 (CET) Date: Wed, 26 Nov 2008 23:36:58 +0100 (CET) Message-Id: <20081126.233658.220882635.mbj@tail-f.com> To: schishol@nortel.com From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4176B276C@zcarhxm2.corp.nortel.com> References: <713043CE8B8E1348AF3C546DBE02C1B4176B276C@zcarhxm2.corp.nortel.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Commons on with-defaults Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Sharon Chisholm" wrote: > 3. The behaviour really needs to be > - no argument: then default behaviour of system (whether to send > defaults or not) > - with-defaults="true": then default values are sent > - with-defaults="false": then default values are not sent > Otherwise there is no way to guarantee that you don't get > default-values. +1 And we should allow for devices which cannot distinguish between defaults and other values to not have to support with-defaults="false". I think it's better that they don't implement it, rather than fake it. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 14:48:22 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 7640228C1C6; Wed, 26 Nov 2008 14:48:22 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90523A6A3A for ; Wed, 26 Nov 2008 14:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lvmi0+JEEQVu for ; Wed, 26 Nov 2008 14:48:21 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 119863A6914 for ; Wed, 26 Nov 2008 14:48:21 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSS3SLsGnVllY9U5E6IGnAujHVn4/5YIt@postini.com; Wed, 26 Nov 2008 14:48:18 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Wed, 26 Nov 2008 14:46:51 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 14:46:50 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 14:46:50 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 14:46:50 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mAQMknM18229; Wed, 26 Nov 2008 14:46:49 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id mAQMffTM051499; Wed, 26 Nov 2008 22:41:42 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200811262241.mAQMffTM051499@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20081126215618.GA6221@elstar.local> Date: Wed, 26 Nov 2008 17:41:41 -0500 From: Phil Shafer X-OriginalArrivalTime: 26 Nov 2008 22:46:50.0415 (UTC) FILETIME=[DECC7BF0:01C95018] MIME-Version: 1.0 Cc: Netconf Subject: Re: [Netconf] confirm WG consensus on potential new WG work-item: notification X-BeenThere: netconf@ietf.org X-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 Juergen Schoenwaelder writes: >If something gets added to the >charter, then I think it must be more concrete than "URGENTLY needed >notifications". My concern is that we have a number of fish in the fire. I would like to see this work happen after the YANG drafts have been put to bed. We are facing agressive deadlines and need eyes to review those documents (and fingers to type them). With resources being scant and getting more so, I'd appreciate delaying this work until we finish other work. I see no notifications that are in the same class of URGENT as completing our data modeling work. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 14:48:22 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 7640228C1C6; Wed, 26 Nov 2008 14:48:22 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90523A6A3A for ; Wed, 26 Nov 2008 14:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lvmi0+JEEQVu for ; Wed, 26 Nov 2008 14:48:21 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 119863A6914 for ; Wed, 26 Nov 2008 14:48:21 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSS3SLsGnVllY9U5E6IGnAujHVn4/5YIt@postini.com; Wed, 26 Nov 2008 14:48:18 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Wed, 26 Nov 2008 14:46:51 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 14:46:50 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 14:46:50 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 14:46:50 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mAQMknM18229; Wed, 26 Nov 2008 14:46:49 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id mAQMffTM051499; Wed, 26 Nov 2008 22:41:42 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200811262241.mAQMffTM051499@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20081126215618.GA6221@elstar.local> Date: Wed, 26 Nov 2008 17:41:41 -0500 From: Phil Shafer X-OriginalArrivalTime: 26 Nov 2008 22:46:50.0415 (UTC) FILETIME=[DECC7BF0:01C95018] MIME-Version: 1.0 Cc: Netconf Subject: Re: [Netconf] confirm WG consensus on potential new WG work-item: notification X-BeenThere: netconf@ietf.org X-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 Juergen Schoenwaelder writes: >If something gets added to the >charter, then I think it must be more concrete than "URGENTLY needed >notifications". My concern is that we have a number of fish in the fire. I would like to see this work happen after the YANG drafts have been put to bed. We are facing agressive deadlines and need eyes to review those documents (and fingers to type them). With resources being scant and getting more so, I'd appreciate delaying this work until we finish other work. I see no notifications that are in the same class of URGENT as completing our data modeling work. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 14:53: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 2529328C14E; Wed, 26 Nov 2008 14:53:35 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A8C3A6C90 for ; Wed, 26 Nov 2008 14:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqJ5lp18BRa3 for ; Wed, 26 Nov 2008 14:53:33 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id D09413A6813 for ; Wed, 26 Nov 2008 14:53:31 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSS3TZ+s3ernpsa9eRIin7Cq41zryq0rb@postini.com; Wed, 26 Nov 2008 14:53:30 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Wed, 26 Nov 2008 14:51:18 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 14:51:17 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 14:51:17 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 14:51:17 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mAQMpGM22125; Wed, 26 Nov 2008 14:51:16 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id mAQMk8WM051551; Wed, 26 Nov 2008 22:46:09 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200811262246.mAQMk8WM051551@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20081126220029.GB6221@elstar.local> Date: Wed, 26 Nov 2008 17:46:08 -0500 From: Phil Shafer X-OriginalArrivalTime: 26 Nov 2008 22:51:17.0370 (UTC) FILETIME=[7DEA95A0:01C95019] MIME-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Commons on with-defaults Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder writes: >I agree - I have been pretty surprised to see with-defaults on the RPC >layer and not the operations layer - looks like a layer violation to >me. I agree. This comment has been made a number of times with the previous draft, but the new draft continues to put it on the element. While I understand this must change to match the WG's opinion if this document become a WG doc, it still surprising. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 14:53: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 2529328C14E; Wed, 26 Nov 2008 14:53:35 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A8C3A6C90 for ; Wed, 26 Nov 2008 14:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqJ5lp18BRa3 for ; Wed, 26 Nov 2008 14:53:33 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id D09413A6813 for ; Wed, 26 Nov 2008 14:53:31 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSS3TZ+s3ernpsa9eRIin7Cq41zryq0rb@postini.com; Wed, 26 Nov 2008 14:53:30 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Wed, 26 Nov 2008 14:51:18 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 14:51:17 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 14:51:17 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 14:51:17 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mAQMpGM22125; Wed, 26 Nov 2008 14:51:16 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id mAQMk8WM051551; Wed, 26 Nov 2008 22:46:09 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200811262246.mAQMk8WM051551@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20081126220029.GB6221@elstar.local> Date: Wed, 26 Nov 2008 17:46:08 -0500 From: Phil Shafer X-OriginalArrivalTime: 26 Nov 2008 22:51:17.0370 (UTC) FILETIME=[7DEA95A0:01C95019] MIME-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Commons on with-defaults Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder writes: >I agree - I have been pretty surprised to see with-defaults on the RPC >layer and not the operations layer - looks like a layer violation to >me. I agree. This comment has been made a number of times with the previous draft, but the new draft continues to put it on the element. While I understand this must change to match the WG's opinion if this document become a WG doc, it still surprising. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 14:56:41 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 5895428C14E; Wed, 26 Nov 2008 14:56:41 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0881E3A6C90 for ; Wed, 26 Nov 2008 14:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 2bFl8Q-z0e5g for ; Wed, 26 Nov 2008 14:56:39 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 342003A6C4F for ; Wed, 26 Nov 2008 14:56:39 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSS3UIVKLotXjGAtC61a9bbVQa+vqbkso@postini.com; Wed, 26 Nov 2008 14:56:37 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Wed, 26 Nov 2008 14:54:23 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 14:54:23 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 14:54:22 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 14:54:22 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mAQMsLM25292; Wed, 26 Nov 2008 14:54:21 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id mAQMnEAp051617; Wed, 26 Nov 2008 22:49:14 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200811262249.mAQMnEAp051617@idle.juniper.net> To: "Bert Wijnen \(IETF\)" In-Reply-To: Date: Wed, 26 Nov 2008 17:49:13 -0500 From: Phil Shafer X-OriginalArrivalTime: 26 Nov 2008 22:54:22.0529 (UTC) FILETIME=[EC479B10:01C95019] MIME-Version: 1.0 Cc: Netconf Subject: Re: [Netconf] confirm WG consensus on potential new WG work-item:notification X-BeenThere: netconf@ietf.org X-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\)" writes: >Sharon has mentioned 2 to the list recently (Iirc) and I have heard = >that Phil has >2 in mind as well. Maybe Phil can post his list. I mentioned thes same two when we spoke about this, but firmly believe there's nothing urgent about either of them. Better to put out nose to the grindstone of finishing off YANG, imho. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 14:56:41 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 5895428C14E; Wed, 26 Nov 2008 14:56:41 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0881E3A6C90 for ; Wed, 26 Nov 2008 14:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 2bFl8Q-z0e5g for ; Wed, 26 Nov 2008 14:56:39 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 342003A6C4F for ; Wed, 26 Nov 2008 14:56:39 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSS3UIVKLotXjGAtC61a9bbVQa+vqbkso@postini.com; Wed, 26 Nov 2008 14:56:37 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Wed, 26 Nov 2008 14:54:23 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 14:54:23 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 14:54:22 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 14:54:22 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mAQMsLM25292; Wed, 26 Nov 2008 14:54:21 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id mAQMnEAp051617; Wed, 26 Nov 2008 22:49:14 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200811262249.mAQMnEAp051617@idle.juniper.net> To: "Bert Wijnen \(IETF\)" In-Reply-To: Date: Wed, 26 Nov 2008 17:49:13 -0500 From: Phil Shafer X-OriginalArrivalTime: 26 Nov 2008 22:54:22.0529 (UTC) FILETIME=[EC479B10:01C95019] MIME-Version: 1.0 Cc: Netconf Subject: Re: [Netconf] confirm WG consensus on potential new WG work-item:notification X-BeenThere: netconf@ietf.org X-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\)" writes: >Sharon has mentioned 2 to the list recently (Iirc) and I have heard = >that Phil has >2 in mind as well. Maybe Phil can post his list. I mentioned thes same two when we spoke about this, but firmly believe there's nothing urgent about either of them. Better to put out nose to the grindstone of finishing off YANG, imho. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 15:10:41 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 608C728C261; Wed, 26 Nov 2008 15:10:41 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2592D28C261 for ; Wed, 26 Nov 2008 15:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.087, 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 cIlWtuKUVbvZ for ; Wed, 26 Nov 2008 15:10:37 -0800 (PST) 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 9A04228C250 for ; Wed, 26 Nov 2008 15:10:37 -0800 (PST) Received: (qmail 97829 invoked from network); 26 Nov 2008 23:10:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 26 Nov 2008 23:10:33 -0000 X-YMail-OSG: z2wpIO4VM1kBsYbtbrpKOHCWf5SC._CT_uCgZCdl19RflrMpB6mBGCLLkW4tZ.D7fwTU4X99Vjc6gISPhwlwqWm1Wsj81UYG8jvtBGDKeLOek4khRbygWJtrRu9PDO0LiOI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <492DD767.4020104@netconfcentral.com> Date: Wed, 26 Nov 2008 15:10:31 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Sharon Chisholm References: <4D7EEB1103FA450A907208A7CCFACC4E@BertLaptop> <713043CE8B8E1348AF3C546DBE02C1B4176B2979@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4176B2979@zcarhxm2.corp.nortel.com> Cc: Netconf Subject: Re: [Netconf] confirm WG consensus on potential new WG work-item:notification X-BeenThere: netconf@ietf.org X-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 Sharon Chisholm wrote: > Hi > > I believe how several people expressed things was a header plus a small > set (1-3) notifications that we really need. > > As indicated, I'm willing to work with the editor to extract out the > appropriate portions of the not-content individual submission that meets > this agreed to scope. First though, we need to agree on what the small > set of notification would be. I'd vote for configuration change events > and software upgrade notifications. > I think it is reasonable to work on very limited content since there are volunteers to work on it (I would be willing to help Sharon if needed). I do not think the YANG schedule has much impact, as long as the notifications use only YANG-compatible data structures. I cannot imagine anything more complicated than a few leafs getting defined now. The focus should be result-oriented. How many header fields can we agree on in 3 months? One? Two? Can we agree on a basic config-change notification as well? I think a very short (4 - 6 month) charter would be appropriate, even though NETMOD is not finished. The same people work on both, so any incompatibilities will get detected early on. > Sharon Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 15:10:41 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 608C728C261; Wed, 26 Nov 2008 15:10:41 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2592D28C261 for ; Wed, 26 Nov 2008 15:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.087, 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 cIlWtuKUVbvZ for ; Wed, 26 Nov 2008 15:10:37 -0800 (PST) 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 9A04228C250 for ; Wed, 26 Nov 2008 15:10:37 -0800 (PST) Received: (qmail 97829 invoked from network); 26 Nov 2008 23:10:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 26 Nov 2008 23:10:33 -0000 X-YMail-OSG: z2wpIO4VM1kBsYbtbrpKOHCWf5SC._CT_uCgZCdl19RflrMpB6mBGCLLkW4tZ.D7fwTU4X99Vjc6gISPhwlwqWm1Wsj81UYG8jvtBGDKeLOek4khRbygWJtrRu9PDO0LiOI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <492DD767.4020104@netconfcentral.com> Date: Wed, 26 Nov 2008 15:10:31 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Sharon Chisholm References: <4D7EEB1103FA450A907208A7CCFACC4E@BertLaptop> <713043CE8B8E1348AF3C546DBE02C1B4176B2979@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4176B2979@zcarhxm2.corp.nortel.com> Cc: Netconf Subject: Re: [Netconf] confirm WG consensus on potential new WG work-item:notification X-BeenThere: netconf@ietf.org X-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 Sharon Chisholm wrote: > Hi > > I believe how several people expressed things was a header plus a small > set (1-3) notifications that we really need. > > As indicated, I'm willing to work with the editor to extract out the > appropriate portions of the not-content individual submission that meets > this agreed to scope. First though, we need to agree on what the small > set of notification would be. I'd vote for configuration change events > and software upgrade notifications. > I think it is reasonable to work on very limited content since there are volunteers to work on it (I would be willing to help Sharon if needed). I do not think the YANG schedule has much impact, as long as the notifications use only YANG-compatible data structures. I cannot imagine anything more complicated than a few leafs getting defined now. The focus should be result-oriented. How many header fields can we agree on in 3 months? One? Two? Can we agree on a basic config-change notification as well? I think a very short (4 - 6 month) charter would be appropriate, even though NETMOD is not finished. The same people work on both, so any incompatibilities will get detected early on. > Sharon Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Nov 26 19:11: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 C1FBF3A6A35; Wed, 26 Nov 2008 19:11:28 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58F3E3A6A35 for ; Wed, 26 Nov 2008 19:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaXKPl5wBM8n for ; Wed, 26 Nov 2008 19:11:26 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 8BC1D3A6806 for ; Wed, 26 Nov 2008 19:11:26 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAZ00MIF2608Q@szxga04-in.huawei.com> for netconf@ietf.org; Thu, 27 Nov 2008 11:10:48 +0800 (CST) Received: from huawei.com ([172.17.1.31]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAZ0041S2602E@szxga04-in.huawei.com> for netconf@ietf.org; Thu, 27 Nov 2008 11:10:48 +0800 (CST) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Thu, 27 Nov 2008 11:10:43 +0800 Date: Thu, 27 Nov 2008 11:10:43 +0800 From: Washam Fan In-reply-to: <20081126.165955.251805489.mbj@tail-f.com> To: Martin Bjorklund Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: zh-CN Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <492D6E51.6070905@netconfcentral.com> <20081126.165955.251805489.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] XPath in RFC 4741 X-BeenThere: netconf@ietf.org X-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, > Andy Bierman wrote: > > Hi, > > > > The details on XPath filtering in 8.9.5.1 are not > > that clear. > > > > There is only a request in the example, but no reply: > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > > > select="top/users/user[name='fred']"/>> > > > > > > Note the bug in the example -- the select string should start > > with an absolute-path (/top instead of top). > > Hmmm.. while I agree that the example should use "/top/...", I think > it is legal to do "top/..." - this will then be evaluated relative to > the context node which is the conceptual node. The section 5.2 in RFC4741 says "NETCONF carries configuration data inside the element that is spFrom netconf-bounces@ietf.org Wed Nov 26 19:11: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 C1FBF3A6A35; Wed, 26 Nov 2008 19:11:28 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58F3E3A6A35 for ; Wed, 26 Nov 2008 19:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaXKPl5wBM8n for ; Wed, 26 Nov 2008 19:11:26 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 8BC1D3A6806 for ; Wed, 26 Nov 2008 19:11:26 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAZ00MIF2608Q@szxga04-in.huawei.com> for netconf@ietf.org; Thu, 27 Nov 2008 11:10:48 +0800 (CST) Received: from huawei.com ([172.17.1.31]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAZ0041S2602E@szxga04-in.huawei.com> for netconf@ietf.org; Thu, 27 Nov 2008 11:10:48 +0800 (CST) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Thu, 27 Nov 2008 11:10:43 +0800 Date: Thu, 27 Nov 2008 11:10:43 +0800 From: Washam Fan In-reply-to: <20081126.165955.251805489.mbj@tail-f.com> To: Martin Bjorklund Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: zh-CN Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <492D6E51.6070905@netconfcentral.com> <20081126.165955.251805489.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] XPath in RFC 4741 X-BeenThere: netconf@ietf.org X-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, > Andy Bierman wrote: > > Hi, > > > > The details on XPath filtering in 8.9.5.1 are not > > that clear. > > > > There is only a request in the example, but no reply: > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > > > select="top/users/user[name='fred']"/>> > > > > > > Note the bug in the example -- the select string should start > > with an absolute-path (/top instead of top). > > Hmmm.. while I agree that the example should use "/top/...", I think > it is legal to do "top/..." - this will then be evaluated relative to > the context node which is the conceptual node. The section 5.2 in RFC4741 says "NETCONF carries configuration data inside the element that is specificecific to device's data model." Shouldn't all configuration data be children of element? Washam _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf to device's data model." Shouldn't all configuration data be children of element? Washam _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Nov 27 00:35: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 3B67928C14C; Thu, 27 Nov 2008 00:35:56 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11DDC28C0E9 for ; Thu, 27 Nov 2008 00:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.200, 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 vTI8HIDyRvgO for ; Thu, 27 Nov 2008 00:35:53 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E854928C129 for ; Thu, 27 Nov 2008 00:35:52 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D6FED210F3; Thu, 27 Nov 2008 09:35:48 +0100 (CET) X-AuditID: c1b4fb3e-aaf7ebb00000537b-da-492e5be47b15 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C1FB121472; Thu, 27 Nov 2008 09:35:48 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 09:35:29 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 09:35:28 +0100 Message-ID: <492E5BD0.9030004@ericsson.com> Date: Thu, 27 Nov 2008 09:35:28 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <4D7EEB1103FA450A907208A7CCFACC4E@BertLaptop> In-Reply-To: <4D7EEB1103FA450A907208A7CCFACC4E@BertLaptop> X-OriginalArrivalTime: 27 Nov 2008 08:35:28.0744 (UTC) FILETIME=[1A29CE80:01C9506B] X-Brightmail-Tracker: AAAAAA== Cc: Netconf Subject: Re: [Netconf] confirm WG consensus on potential new WG work-item: notification X-BeenThere: netconf@ietf.org X-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 agree with Jurgen, that we can not update the charter without defining what notifications are urgent - I don't believe we can finish anything before YANG - I agree with Phil that resources should be concentrated on the current netconf/netmod drafts So I am against this work. On the other hand if it does go ahead, my priorities would be: Some common header data: - eventIdentifier, eventclass, sending resource Notifications: - conveying results to long running operations Balazs Bert Wijnen (IETF) wrote: > WG participants, > > At our NetConf Session at IETF73, the people in the room expressed strong > support for the following statements: > > - We do not want to define extensive Notification content NOW > - We just want to define content for notifications that we URGENTLY > need now (within the next year). That is one or two notifications > - Less urgent notification content we can define once the NETMOD > results become available > > The WG chairs consider this to be WG consensus. If anyone on the mailing > list does not agree, please speak up before Dec 3rd 2008. That is one > week. > We want to try and get updated charter to IESG before X-mas. > > The WG chairs do not want to consider > draft-chisholm-netconf-not-content-00.txt > as a starting point. The reason being that it wants to do much more than > the > minimal approach that is expressed above. > > The WG chairs will propose/draft new charter text that we will circulate > for consensus checking. Once we have such a draft text, we will also > call for volunteers to become editors of the document. > > Bert and Mehmet > > > _______________________________________________ > 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 Thu Nov 27 00:35: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 3B67928C14C; Thu, 27 Nov 2008 00:35:56 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11DDC28C0E9 for ; Thu, 27 Nov 2008 00:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.200, 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 vTI8HIDyRvgO for ; Thu, 27 Nov 2008 00:35:53 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E854928C129 for ; Thu, 27 Nov 2008 00:35:52 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D6FED210F3; Thu, 27 Nov 2008 09:35:48 +0100 (CET) X-AuditID: c1b4fb3e-aaf7ebb00000537b-da-492e5be47b15 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C1FB121472; Thu, 27 Nov 2008 09:35:48 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 09:35:29 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 09:35:28 +0100 Message-ID: <492E5BD0.9030004@ericsson.com> Date: Thu, 27 Nov 2008 09:35:28 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <4D7EEB1103FA450A907208A7CCFACC4E@BertLaptop> In-Reply-To: <4D7EEB1103FA450A907208A7CCFACC4E@BertLaptop> X-OriginalArrivalTime: 27 Nov 2008 08:35:28.0744 (UTC) FILETIME=[1A29CE80:01C9506B] X-Brightmail-Tracker: AAAAAA== Cc: Netconf Subject: Re: [Netconf] confirm WG consensus on potential new WG work-item: notification X-BeenThere: netconf@ietf.org X-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 agree with Jurgen, that we can not update the charter without defining what notifications are urgent - I don't believe we can finish anything before YANG - I agree with Phil that resources should be concentrated on the current netconf/netmod drafts So I am against this work. On the other hand if it does go ahead, my priorities would be: Some common header data: - eventIdentifier, eventclass, sending resource Notifications: - conveying results to long running operations Balazs Bert Wijnen (IETF) wrote: > WG participants, > > At our NetConf Session at IETF73, the people in the room expressed strong > support for the following statements: > > - We do not want to define extensive Notification content NOW > - We just want to define content for notifications that we URGENTLY > need now (within the next year). That is one or two notifications > - Less urgent notification content we can define once the NETMOD > results become available > > The WG chairs consider this to be WG consensus. If anyone on the mailing > list does not agree, please speak up before Dec 3rd 2008. That is one > week. > We want to try and get updated charter to IESG before X-mas. > > The WG chairs do not want to consider > draft-chisholm-netconf-not-content-00.txt > as a starting point. The reason being that it wants to do much more than > the > minimal approach that is expressed above. > > The WG chairs will propose/draft new charter text that we will circulate > for consensus checking. Once we have such a draft text, we will also > call for volunteers to become editors of the document. > > Bert and Mehmet > > > _______________________________________________ > 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 Thu Nov 27 01:07: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 E9D513A6B92; Thu, 27 Nov 2008 01:07:26 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3AA73A6AED for ; Thu, 27 Nov 2008 01:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150, 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 emy5bVer+Rpm for ; Thu, 27 Nov 2008 01:07:24 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 744883A6B92 for ; Thu, 27 Nov 2008 01:07:23 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B382E225C3; Thu, 27 Nov 2008 10:06:48 +0100 (CET) X-AuditID: c1b4fb3c-ae8cfbb0000015b5-44-492e61fcefb0 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A910B22740; Thu, 27 Nov 2008 10:01:48 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 10:01:28 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 10:01:27 +0100 Message-ID: <492E61E7.9000005@ericsson.com> Date: Thu, 27 Nov 2008 10:01:27 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <713043CE8B8E1348AF3C546DBE02C1B4176B276C@zcarhxm2.corp.nortel.com> <20081126220029.GB6221@elstar.local> <492DC7E6.9050001@netconfcentral.com> <20081126.233407.202709362.mbj@tail-f.com> In-Reply-To: <20081126.233407.202709362.mbj@tail-f.com> X-OriginalArrivalTime: 27 Nov 2008 09:01:27.0985 (UTC) FILETIME=[BB8B1A10:01C9506E] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Commons on with-defaults Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 agree that the proper place for the with-defaults attribute would be the operation, however we need WG consensus that 4741 does allow this. As I see it the following people agree with the statement: "4741 allows new RFCs to add attributes to the XML elements in the XSD schema." Phil, Martin, Balazs, Sharon, Jurgen Please state if I am wrong !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Opinion by others? This raises a number of other questions: 1) If attributes can be added, can new elements be added as well? I would say yes. 2) If we agree that standard track RFC can add stuff, can individual agent, manager SW also add attributes and still claim compliance? E.g. If they define a proprietary capability. Balazs Martin Bjorklund wrote: > Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Wed, Nov 26, 2008 at 12:56:49PM -0500, Sharon Chisholm wrote: >>> >>>> 2. The with-defaults argument should go on the operation itself. >>>> . From >>>> reading section 7.1 there seems to be some sort of issue with placing it >>>> there, but I don't fully understand it. Putting the parameter on the >>>> portion will change the way the operations need to be parsed and >>>> handled by the system doesn't it? Perhaps I'll play a bit with the XSDs. >>> I agree - I have been pretty surprised to see with-defaults on the RPC >>> layer and not the operations layer - looks like a layer violation to >>> me. >>> >> The reason for this is that the element already has >> to accept any XML attribute and return it unchanged. >> It was the path of least resistance, especially for >> a vendor extension. >> >> For a standard, normal element-based parameters would >> be the most YANG-ish thing to do. > > I agree. > > The problem is that the XSD in 4741 is not an open schema in that it > does not allow unknown elements or attributes (with the exception of > ). I think that this was not the intention with the spec, and > that it should be clarified in 4741bis. I think the intention was > that capabilities could add parameters to the operations, even though > not explicitly allowed by the XSD. We can either make the XSD > explicitly open (that'll be ugly though - XSD 1.1 anyone ;-), or we > can just state this in text. > > > /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 Thu Nov 27 01:07:27 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 E9D513A6B92; Thu, 27 Nov 2008 01:07:26 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3AA73A6AED for ; Thu, 27 Nov 2008 01:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150, 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 emy5bVer+Rpm for ; Thu, 27 Nov 2008 01:07:24 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 744883A6B92 for ; Thu, 27 Nov 2008 01:07:23 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B382E225C3; Thu, 27 Nov 2008 10:06:48 +0100 (CET) X-AuditID: c1b4fb3c-ae8cfbb0000015b5-44-492e61fcefb0 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A910B22740; Thu, 27 Nov 2008 10:01:48 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 10:01:28 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 10:01:27 +0100 Message-ID: <492E61E7.9000005@ericsson.com> Date: Thu, 27 Nov 2008 10:01:27 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <713043CE8B8E1348AF3C546DBE02C1B4176B276C@zcarhxm2.corp.nortel.com> <20081126220029.GB6221@elstar.local> <492DC7E6.9050001@netconfcentral.com> <20081126.233407.202709362.mbj@tail-f.com> In-Reply-To: <20081126.233407.202709362.mbj@tail-f.com> X-OriginalArrivalTime: 27 Nov 2008 09:01:27.0985 (UTC) FILETIME=[BB8B1A10:01C9506E] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Commons on with-defaults Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 agree that the proper place for the with-defaults attribute would be the operation, however we need WG consensus that 4741 does allow this. As I see it the following people agree with the statement: "4741 allows new RFCs to add attributes to the XML elements in the XSD schema." Phil, Martin, Balazs, Sharon, Jurgen Please state if I am wrong !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Opinion by others? This raises a number of other questions: 1) If attributes can be added, can new elements be added as well? I would say yes. 2) If we agree that standard track RFC can add stuff, can individual agent, manager SW also add attributes and still claim compliance? E.g. If they define a proprietary capability. Balazs Martin Bjorklund wrote: > Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Wed, Nov 26, 2008 at 12:56:49PM -0500, Sharon Chisholm wrote: >>> >>>> 2. The with-defaults argument should go on the operation itself. >>>> . From >>>> reading section 7.1 there seems to be some sort of issue with placing it >>>> there, but I don't fully understand it. Putting the parameter on the >>>> portion will change the way the operations need to be parsed and >>>> handled by the system doesn't it? Perhaps I'll play a bit with the XSDs. >>> I agree - I have been pretty surprised to see with-defaults on the RPC >>> layer and not the operations layer - looks like a layer violation to >>> me. >>> >> The reason for this is that the element already has >> to accept any XML attribute and return it unchanged. >> It was the path of least resistance, especially for >> a vendor extension. >> >> For a standard, normal element-based parameters would >> be the most YANG-ish thing to do. > > I agree. > > The problem is that the XSD in 4741 is not an open schema in that it > does not allow unknown elements or attributes (with the exception of > ). I think that this was not the intention with the spec, and > that it should be clarified in 4741bis. I think the intention was > that capabilities could add parameters to the operations, even though > not explicitly allowed by the XSD. We can either make the XSD > explicitly open (that'll be ugly though - XSD 1.1 anyone ;-), or we > can just state this in text. > > > /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 Thu Nov 27 01:16: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 A5FA428C267; Thu, 27 Nov 2008 01:16:44 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0491628C266 for ; Thu, 27 Nov 2008 01:16:43 -0800 (PST) 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 UHri+zCRXxBO for ; Thu, 27 Nov 2008 01:16:42 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3A01228C268 for ; Thu, 27 Nov 2008 01:16:42 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 6848D76C54C; Thu, 27 Nov 2008 10:16:38 +0100 (CET) Date: Thu, 27 Nov 2008 10:16:38 +0100 (CET) Message-Id: <20081127.101638.39754571.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <492E61E7.9000005@ericsson.com> References: <492DC7E6.9050001@netconfcentral.com> <20081126.233407.202709362.mbj@tail-f.com> <492E61E7.9000005@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] Commons on with-defaults Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: > This raises a number of other questions: > 1) If attributes can be added, can new elements be added as well? I would say > yes. Yes. And I agree with Andy that with-defaults should probably be an element rather than an attribute. > 2) If we agree that standard track RFC can add stuff, can individual agent, > manager SW also add attributes and still claim compliance? E.g. If they define > a proprietary capability. Yes. The WG did talk about this issue at some point (Vancouver?), and IIRC there was consensus that a capability can *add* to existing operations, but there was not consensus that a capability can *change* existing behavior. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Nov 27 01:16: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 A5FA428C267; Thu, 27 Nov 2008 01:16:44 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0491628C266 for ; Thu, 27 Nov 2008 01:16:43 -0800 (PST) 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 UHri+zCRXxBO for ; Thu, 27 Nov 2008 01:16:42 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3A01228C268 for ; Thu, 27 Nov 2008 01:16:42 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 6848D76C54C; Thu, 27 Nov 2008 10:16:38 +0100 (CET) Date: Thu, 27 Nov 2008 10:16:38 +0100 (CET) Message-Id: <20081127.101638.39754571.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <492E61E7.9000005@ericsson.com> References: <492DC7E6.9050001@netconfcentral.com> <20081126.233407.202709362.mbj@tail-f.com> <492E61E7.9000005@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] Commons on with-defaults Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: > This raises a number of other questions: > 1) If attributes can be added, can new elements be added as well? I would say > yes. Yes. And I agree with Andy that with-defaults should probably be an element rather than an attribute. > 2) If we agree that standard track RFC can add stuff, can individual agent, > manager SW also add attributes and still claim compliance? E.g. If they define > a proprietary capability. Yes. The WG did talk about this issue at some point (Vancouver?), and IIRC there was consensus that a capability can *add* to existing operations, but there was not consensus that a capability can *change* existing behavior. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Nov 27 01:36:11 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 C85B63A6B70; Thu, 27 Nov 2008 01:36:11 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FA403A6B70 for ; Thu, 27 Nov 2008 01:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89v5+7Et7X-k for ; Thu, 27 Nov 2008 01:36:09 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 13ABE3A681C for ; Thu, 27 Nov 2008 01:36:08 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mAR9a0Z0011996; Thu, 27 Nov 2008 10:36:00 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 10:36:00 +0100 Message-ID: <492E6999.5020302@s3group.com> Date: Thu, 27 Nov 2008 10:34:17 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: Andy Bierman References: <492D6E51.6070905@netconfcentral.com> <492D752C.5050605@s3group.com> <492D837C.3020204@netconfcentral.com> In-Reply-To: <492D837C.3020204@netconfcentral.com> X-OriginalArrivalTime: 27 Nov 2008 09:36:00.0240 (UTC) FILETIME=[8EB41F00:01C95073] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Thu, 27 Nov 2008 10:36:04 +0100 (CET) Cc: NETCONF Subject: Re: [Netconf] XPath in RFC 4741 X-BeenThere: netconf@ietf.org X-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, Andy Bierman wrote: > Tomasz Mikolajczyk wrote: >> Hi, >> >> Andy Bierman wrote: >> >>> What about something like select="//name"? >>> >>> (B) >>> >> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >>> >>> fred >>> barney >>> eth0 >>> eth1 >>> >>> >>> >>> >>> >>> Andy >>> >> >> Such response is inconsistent with the subtree filtering rules and >> rather should be: >> > > Where does it say in 4741 that XPath filtered output > looks the same as subtree-filtered output? > RFC 4741 seems to say "use XPath and do what XPath > says to do". That was the intent of the WG at the > time it was written. Nowhere. NETCONF RFC is not precise in many places. Can you see any advantages of such behavior when a server returns different output format depending on the filter mechanism? IMO, this makes a client much more complicated. > It seems to me that XPath 1.0 does not return all > the ancestor nodes in a node-set result, but rather > the requested nodes. > > The RFC does not say what to do if the select expression > is not a node-set, but another result type (string, boolean > or number). I assume an empty response will be given in those > cases. Please consider the following XML request: fred Assuming that it means asking about an surname attribute, an application is requested only for this attribute and returns only its value (for instance "Flinston") instead of the whole XML. There is no need at all that server sends to the application the whole XML and the application returns ready XML response. It's the NETCONF server task to opaque the response according to the request (data model) and NETCONF filtering rules. The device shouldn't know anything about the NETCONF format. > IMO, this is a serious issue. > One could argue that off-the-shelf XPath tools > are rendered useless if the agent returns (A) > instead of (B). I can see how most > > XPath is intended to be used in some application context, > where something is being done to the result nodes. > The natural NETCONF application is 'xedit': > > path = "/interfaces/interface[name='fred']/mtu" > confignode = xget(select=path) > if confignode < 1518: > confignode = 1518 > xedit(select=path, operation='replace', value=confignode) > > > In this hypothetical application, it makes much more sense to > do what XPath says instead of making up rules about returning > all the ancestor nodes. > > The xedit syntax does not have to be aligned with > the XPath filtered retrieval output, but it makes code easier > for some things (and harder for others). XPath set is another > power saw that must be used really carefully: > > xedit(select="/interfaces/interface/mtu", value=1518) > > Or even: > > lockid = partial-lock(select="/interfaces/interface/mtu") > if lockid: > xedit(select="/interfaces/interface/mtu", value=1518) > partial-unlock(lock-id) > >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> >> >> fred >> >> >> barney >> >> >> >> eth0 >> >> >> eth1 >> >> >> >> >> >> Regards, >> Tomasz Mikolajczyk >> > > > Andy > Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Nov 27 01:36:11 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 C85B63A6B70; Thu, 27 Nov 2008 01:36:11 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FA403A6B70 for ; Thu, 27 Nov 2008 01:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89v5+7Et7X-k for ; Thu, 27 Nov 2008 01:36:09 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 13ABE3A681C for ; Thu, 27 Nov 2008 01:36:08 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mAR9a0Z0011996; Thu, 27 Nov 2008 10:36:00 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 10:36:00 +0100 Message-ID: <492E6999.5020302@s3group.com> Date: Thu, 27 Nov 2008 10:34:17 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: Andy Bierman References: <492D6E51.6070905@netconfcentral.com> <492D752C.5050605@s3group.com> <492D837C.3020204@netconfcentral.com> In-Reply-To: <492D837C.3020204@netconfcentral.com> X-OriginalArrivalTime: 27 Nov 2008 09:36:00.0240 (UTC) FILETIME=[8EB41F00:01C95073] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Thu, 27 Nov 2008 10:36:04 +0100 (CET) Cc: NETCONF Subject: Re: [Netconf] XPath in RFC 4741 X-BeenThere: netconf@ietf.org X-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, Andy Bierman wrote: > Tomasz Mikolajczyk wrote: >> Hi, >> >> Andy Bierman wrote: >> >>> What about something like select="//name"? >>> >>> (B) >>> >> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >>> >>> fred >>> barney >>> eth0 >>> eth1 >>> >>> >>> >>> >>> >>> Andy >>> >> >> Such response is inconsistent with the subtree filtering rules and >> rather should be: >> > > Where does it say in 4741 that XPath filtered output > looks the same as subtree-filtered output? > RFC 4741 seems to say "use XPath and do what XPath > says to do". That was the intent of the WG at the > time it was written. Nowhere. NETCONF RFC is not precise in many places. Can you see any advantages of such behavior when a server returns different output format depending on the filter mechanism? IMO, this makes a client much more complicated. > It seems to me that XPath 1.0 does not return all > the ancestor nodes in a node-set result, but rather > the requested nodes. > > The RFC does not say what to do if the select expression > is not a node-set, but another result type (string, boolean > or number). I assume an empty response will be given in those > cases. Please consider the following XML request: fred Assuming that it means asking about an surname attribute, an application is requested only for this attribute and returns only its value (for instance "Flinston") instead of the whole XML. There is no need at all that server sends to the application the whole XML and the application returns ready XML response. It's the NETCONF server task to opaque the response according to the request (data model) and NETCONF filtering rules. The device shouldn't know anything about the NETCONF format. > IMO, this is a serious issue. > One could argue that off-the-shelf XPath tools > are rendered useless if the agent returns (A) > instead of (B). I can see how most > > XPath is intended to be used in some application context, > where something is being done to the result nodes. > The natural NETCONF application is 'xedit': > > path = "/interfaces/interface[name='fred']/mtu" > confignode = xget(select=path) > if confignode < 1518: > confignode = 1518 > xedit(select=path, operation='replace', value=confignode) > > > In this hypothetical application, it makes much more sense to > do what XPath says instead of making up rules about returning > all the ancestor nodes. > > The xedit syntax does not have to be aligned with > the XPath filtered retrieval output, but it makes code easier > for some things (and harder for others). XPath set is another > power saw that must be used really carefully: > > xedit(select="/interfaces/interface/mtu", value=1518) > > Or even: > > lockid = partial-lock(select="/interfaces/interface/mtu") > if lockid: > xedit(select="/interfaces/interface/mtu", value=1518) > partial-unlock(lock-id) > >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> >> >> fred >> >> >> barney >> >> >> >> eth0 >> >> >> eth1 >> >> >> >> >> >> Regards, >> Tomasz Mikolajczyk >> > > > Andy > Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Nov 27 03:36: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 519C33A6BA2; Thu, 27 Nov 2008 03:36:06 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BB683A6BA2 for ; Thu, 27 Nov 2008 03:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.046 X-Spam-Level: X-Spam-Status: No, score=0.046 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqsQRuu8vL+V for ; Thu, 27 Nov 2008 03:36:04 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 4D7473A67D1 for ; Thu, 27 Nov 2008 03:36:04 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1L5fA8-0004q1-As for netconf@ietf.org; Thu, 27 Nov 2008 12:36:00 +0100 Message-ID: <2885EDEF01874B00B06E4DD515C469C8@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Thu, 27 Nov 2008 12:35:31 +0100 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] Calrification: confirm WG consensus on potential new WG work-item:notification X-BeenThere: netconf@ietf.org X-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 Dear Netconf WG participants, It seems that some people who expressed their opinion in our sesion at IETF73 are changing their minds. And some people who did express their opinion are doing so again here on the mailing list. Since we only counted the number of people in favor or against this work-item and since we did NOT write down names, it becomes difficult to judge (rough) consensus. So to make that easier, we ask EVERYONE to express their opinion on the mailing list again, ALSO those who already did so at our session in Minneapolis. Bert and Mehmet ----- Original Message ----- From: Bert Wijnen (IETF) To: Netconf Sent: Wednesday, November 26, 2008 6:56 PM Subject: [Netconf] confirm WG consensus on potential new WG work-item:notification WG participants, At our NetConf Session at IETF73, the people in the room expressed strong support for the following statements: - We do not want to define extensive Notification content NOW - We just want to define content for notifications that we URGENTLY need now (within the next year). That is one or two notifications - Less urgent notification content we can define once the NETMOD results become available The WG chairs consider this to be WG consensus. If anyone on the mailing list does not agree, please speak up before Dec 3rd 2008. That is one week. We want to try and get updated charter to IESG before X-mas. The WG chairs do not want to consider draft-chisholm-netconf-not-content-00.txt as a starting point. The reason being that it wants to do much more than the minimal approach that is expressed above. The WG chairs will propose/draft new charter text that we will circulate for consensus checking. Once we have such a draft text, we will also call for volunteers to become editors of the document. Bert and Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Nov 27 03:36: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 519C33A6BA2; Thu, 27 Nov 2008 03:36:06 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BB683A6BA2 for ; Thu, 27 Nov 2008 03:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.046 X-Spam-Level: X-Spam-Status: No, score=0.046 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqsQRuu8vL+V for ; Thu, 27 Nov 2008 03:36:04 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 4D7473A67D1 for ; Thu, 27 Nov 2008 03:36:04 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1L5fA8-0004q1-As for netconf@ietf.org; Thu, 27 Nov 2008 12:36:00 +0100 Message-ID: <2885EDEF01874B00B06E4DD515C469C8@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Thu, 27 Nov 2008 12:35:31 +0100 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] Calrification: confirm WG consensus on potential new WG work-item:notification X-BeenThere: netconf@ietf.org X-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 Dear Netconf WG participants, It seems that some people who expressed their opinion in our sesion at IETF73 are changing their minds. And some people who did express their opinion are doing so again here on the mailing list. Since we only counted the number of people in favor or against this work-item and since we did NOT write down names, it becomes difficult to judge (rough) consensus. So to make that easier, we ask EVERYONE to express their opinion on the mailing list again, ALSO those who already did so at our session in Minneapolis. Bert and Mehmet ----- Original Message ----- From: Bert Wijnen (IETF) To: Netconf Sent: Wednesday, November 26, 2008 6:56 PM Subject: [Netconf] confirm WG consensus on potential new WG work-item:notification WG participants, At our NetConf Session at IETF73, the people in the room expressed strong support for the following statements: - We do not want to define extensive Notification content NOW - We just want to define content for notifications that we URGENTLY need now (within the next year). That is one or two notifications - Less urgent notification content we can define once the NETMOD results become available The WG chairs consider this to be WG consensus. If anyone on the mailing list does not agree, please speak up before Dec 3rd 2008. That is one week. We want to try and get updated charter to IESG before X-mas. The WG chairs do not want to consider draft-chisholm-netconf-not-content-00.txt as a starting point. The reason being that it wants to do much more than the minimal approach that is expressed above. The WG chairs will propose/draft new charter text that we will circulate for consensus checking. Once we have such a draft text, we will also call for volunteers to become editors of the document. Bert and Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Nov 27 09:15: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 C23CF3A696B; Thu, 27 Nov 2008 09:15:37 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 168543A6993 for ; Thu, 27 Nov 2008 09:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frJ3151YKx1b for ; Thu, 27 Nov 2008 09:15:35 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 01A7E3A696B for ; Thu, 27 Nov 2008 09:15:34 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mARHFRNt019830 for ; Thu, 27 Nov 2008 18:15:27 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 18:15:27 +0100 Message-ID: <492ED548.20105@s3group.com> Date: Thu, 27 Nov 2008 18:13:44 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: NETCONF X-OriginalArrivalTime: 27 Nov 2008 17:15:27.0682 (UTC) FILETIME=[BE2DF220:01C950B3] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Thu, 27 Nov 2008 18:15:29 +0100 (CET) Subject: [Netconf] test-option in edit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, The RFC 4741 in section 7.2 says: "test-option: The test-option element may be specified only if the device advertises the :validate capability (Section 8.6). The test-option element has one of the following values: test-then-set: Perform a validation test before attempting to set. If validation errors occur, do not perform the operation. This is the default test-option. set: Perform a set without a validation test first. " Does it mean that the "test-option=set" value is the same as "normal" edit-config behavior, i.e. as without :validate capability advertised? If it does, I think the "set" value should be the default one and could be specified in the request no matter if the :validate capability is advertised or not. The "test-then-set" value would be allowed to use only if a server supports the :validate capability. Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Nov 27 09:15: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 C23CF3A696B; Thu, 27 Nov 2008 09:15:37 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 168543A6993 for ; Thu, 27 Nov 2008 09:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frJ3151YKx1b for ; Thu, 27 Nov 2008 09:15:35 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 01A7E3A696B for ; Thu, 27 Nov 2008 09:15:34 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mARHFRNt019830 for ; Thu, 27 Nov 2008 18:15:27 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 18:15:27 +0100 Message-ID: <492ED548.20105@s3group.com> Date: Thu, 27 Nov 2008 18:13:44 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: NETCONF X-OriginalArrivalTime: 27 Nov 2008 17:15:27.0682 (UTC) FILETIME=[BE2DF220:01C950B3] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Thu, 27 Nov 2008 18:15:29 +0100 (CET) Subject: [Netconf] test-option in edit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, The RFC 4741 in section 7.2 says: "test-option: The test-option element may be specified only if the device advertises the :validate capability (Section 8.6). The test-option element has one of the following values: test-then-set: Perform a validation test before attempting to set. If validation errors occur, do not perform the operation. This is the default test-option. set: Perform a set without a validation test first. " Does it mean that the "test-option=set" value is the same as "normal" edit-config behavior, i.e. as without :validate capability advertised? If it does, I think the "set" value should be the default one and could be specified in the request no matter if the :validate capability is advertised or not. The "test-then-set" value would be allowed to use only if a server supports the :validate capability. Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Nov 27 09:40: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 170CB3A6951; Thu, 27 Nov 2008 09:40:50 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FB843A69A8 for ; Thu, 27 Nov 2008 09:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.083, 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 xua3Yu22EiHg for ; Thu, 27 Nov 2008 09:40:47 -0800 (PST) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 4783C3A6908 for ; Thu, 27 Nov 2008 09:40:41 -0800 (PST) Received: (qmail 7272 invoked from network); 27 Nov 2008 17:40:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 27 Nov 2008 17:40:36 -0000 X-YMail-OSG: dqNT0pgVM1kBsq_mW56q2WZZ7RhDl5qY_.YtPhiveS1HF75Uifvv4Sjzqnv7sRaTz0HOKs0J5ZPo78Xazk1EoKxgSC.RxLNBvjaUuD.XBFaXHvcuhqev.qCxFMKskhMvKeQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <492EDB92.9020007@netconfcentral.com> Date: Thu, 27 Nov 2008 09:40:34 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Tomasz Mikolajczyk References: <492ED548.20105@s3group.com> In-Reply-To: <492ED548.20105@s3group.com> Cc: NETCONF Subject: Re: [Netconf] test-option in edit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Tomasz Mikolajczyk wrote: > Hi, > > The RFC 4741 in section 7.2 says: > > "test-option: > > The test-option element may be specified only if the device > advertises the :validate capability (Section 8.6). > > The test-option element has one of the following values: > > test-then-set: Perform a validation test before attempting to > set. If validation errors occur, do not perform the > operation. This is the default test-option. > > set: Perform a set without a validation test first. > " > > Does it mean that the "test-option=set" value is the same as "normal" > edit-config behavior, i.e. as without :validate capability advertised? yes > If it does, I think the "set" value should be the default one and could > be specified in the request no matter if the :validate capability is > advertised or not. The "test-then-set" value would be allowed to use > only if a server supports the :validate capability. > I disagree. The default should be to do the most validation available, not the least. I agree that this knob should always be accepted if the value is 'set', regardless of the :validate capability. Note that YANG must, unique, and keyref validation will probably require an agent to run its validation code anytime the config is changed. But since the config is never allowed to be invalid, then there isn't much reason to have this knob at all. The best change would be to get rid of test-option completely. > Tomasz Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Nov 27 09:40: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 170CB3A6951; Thu, 27 Nov 2008 09:40:50 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FB843A69A8 for ; Thu, 27 Nov 2008 09:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.083, 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 xua3Yu22EiHg for ; Thu, 27 Nov 2008 09:40:47 -0800 (PST) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 4783C3A6908 for ; Thu, 27 Nov 2008 09:40:41 -0800 (PST) Received: (qmail 7272 invoked from network); 27 Nov 2008 17:40:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 27 Nov 2008 17:40:36 -0000 X-YMail-OSG: dqNT0pgVM1kBsq_mW56q2WZZ7RhDl5qY_.YtPhiveS1HF75Uifvv4Sjzqnv7sRaTz0HOKs0J5ZPo78Xazk1EoKxgSC.RxLNBvjaUuD.XBFaXHvcuhqev.qCxFMKskhMvKeQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <492EDB92.9020007@netconfcentral.com> Date: Thu, 27 Nov 2008 09:40:34 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Tomasz Mikolajczyk References: <492ED548.20105@s3group.com> In-Reply-To: <492ED548.20105@s3group.com> Cc: NETCONF Subject: Re: [Netconf] test-option in edit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Tomasz Mikolajczyk wrote: > Hi, > > The RFC 4741 in section 7.2 says: > > "test-option: > > The test-option element may be specified only if the device > advertises the :validate capability (Section 8.6). > > The test-option element has one of the following values: > > test-then-set: Perform a validation test before attempting to > set. If validation errors occur, do not perform the > operation. This is the default test-option. > > set: Perform a set without a validation test first. > " > > Does it mean that the "test-option=set" value is the same as "normal" > edit-config behavior, i.e. as without :validate capability advertised? yes > If it does, I think the "set" value should be the default one and could > be specified in the request no matter if the :validate capability is > advertised or not. The "test-then-set" value would be allowed to use > only if a server supports the :validate capability. > I disagree. The default should be to do the most validation available, not the least. I agree that this knob should always be accepted if the value is 'set', regardless of the :validate capability. Note that YANG must, unique, and keyref validation will probably require an agent to run its validation code anytime the config is changed. But since the config is never allowed to be invalid, then there isn't much reason to have this knob at all. The best change would be to get rid of test-option completely. > Tomasz Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Nov 27 11:36: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 A1D7428C162; Thu, 27 Nov 2008 11:36:30 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D17F3A6A46 for ; Thu, 27 Nov 2008 11:36:29 -0800 (PST) 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 g+EzTY0ZadHh for ; Thu, 27 Nov 2008 11:36:28 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A02DE3A69E5 for ; Thu, 27 Nov 2008 11:36:28 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1435B76C517; Thu, 27 Nov 2008 20:36:24 +0100 (CET) Date: Thu, 27 Nov 2008 20:36:23 +0100 (CET) Message-Id: <20081127.203623.123935533.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <492EDB92.9020007@netconfcentral.com> References: <492ED548.20105@s3group.com> <492EDB92.9020007@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] test-option in edit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: > The best change would be to get rid of test-option completely. Some implementations (including yours I believe) also allow the value "test-only" for test-option. By using this value, you can validate an edit-config PDU. If I understand things correctly, this was supposed to be covered by the operation, but as we have discussed serveral times earlier, this didn't work. So I would rather like to see "test-only" standardized. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Nov 27 11:36: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 A1D7428C162; Thu, 27 Nov 2008 11:36:30 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D17F3A6A46 for ; Thu, 27 Nov 2008 11:36:29 -0800 (PST) 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 g+EzTY0ZadHh for ; Thu, 27 Nov 2008 11:36:28 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A02DE3A69E5 for ; Thu, 27 Nov 2008 11:36:28 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1435B76C517; Thu, 27 Nov 2008 20:36:24 +0100 (CET) Date: Thu, 27 Nov 2008 20:36:23 +0100 (CET) Message-Id: <20081127.203623.123935533.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <492EDB92.9020007@netconfcentral.com> References: <492ED548.20105@s3group.com> <492EDB92.9020007@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] test-option in edit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: > The best change would be to get rid of test-option completely. Some implementations (including yours I believe) also allow the value "test-only" for test-option. By using this value, you can validate an edit-config PDU. If I understand things correctly, this was supposed to be covered by the operation, but as we have discussed serveral times earlier, this didn't work. So I would rather like to see "test-only" standardized. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Nov 27 12:51:08 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 295DA3A67F4; Thu, 27 Nov 2008 12:51:08 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7278D3A67F4 for ; Thu, 27 Nov 2008 12:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.080, 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 8taMRjPBk3JY for ; Thu, 27 Nov 2008 12:51:05 -0800 (PST) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id BF56E3A6452 for ; Thu, 27 Nov 2008 12:51:05 -0800 (PST) Received: (qmail 33308 invoked from network); 27 Nov 2008 20:51:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 27 Nov 2008 20:51:00 -0000 X-YMail-OSG: Y0.KdwUVM1mKbQ5OpSrF4wTJhKaNtvb4wU1s7dsp9moNTLPRJBvvjtz1za0dpET57PeOPUlUCp3B0Mxh.MsmQRvDADq_eWSpAWA.uhjVaBHkrXAWzlCLVg7ehOq9h8_SsBNmXyAwM8TrP9ZZ8L4Jo8ZQ X-Yahoo-Newman-Property: ymail-3 Message-ID: <492F0832.4020409@netconfcentral.com> Date: Thu, 27 Nov 2008 12:50:58 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <492ED548.20105@s3group.com> <492EDB92.9020007@netconfcentral.com> <20081127.203623.123935533.mbj@tail-f.com> In-Reply-To: <20081127.203623.123935533.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] test-option in edit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: >> The best change would be to get rid of test-option completely. > > Some implementations (including yours I believe) also allow the value > "test-only" for test-option. By using this value, you can validate an > edit-config PDU. If I understand things correctly, this was supposed > to be covered by the operation, but as we have discussed > serveral times earlier, this didn't work. So I would rather like to > see "test-only" standardized. > I agree test-option=test-only is more useful, perhaps a different use-case. The only use for the current enums would be if you wanted to force or avoid a validate on the candidate config each time you did an incremental edit-config. I don't know why that is useful, which is why Tomasz wants to change the default to 'set'. Most implementations (including mine) do not run all the 'commit-tests' on edit-config operations to candidate, since the whole point of this target is to allow incremental edits which may not be valid until all the edits are done. I'm currently implementing this default wrong for candidate, so thanks for pointing that out. You have to run explicitly to run the 'commit-tests' on candidate. I ignore test-then-set I guess. I changed my mind about removing this knob. I forgot about test-only. The default should be set, since that is the right thing for candidate, and the same as test-then-set for running. > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Nov 27 12:51:08 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 295DA3A67F4; Thu, 27 Nov 2008 12:51:08 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7278D3A67F4 for ; Thu, 27 Nov 2008 12:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.080, 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 8taMRjPBk3JY for ; Thu, 27 Nov 2008 12:51:05 -0800 (PST) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id BF56E3A6452 for ; Thu, 27 Nov 2008 12:51:05 -0800 (PST) Received: (qmail 33308 invoked from network); 27 Nov 2008 20:51:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 27 Nov 2008 20:51:00 -0000 X-YMail-OSG: Y0.KdwUVM1mKbQ5OpSrF4wTJhKaNtvb4wU1s7dsp9moNTLPRJBvvjtz1za0dpET57PeOPUlUCp3B0Mxh.MsmQRvDADq_eWSpAWA.uhjVaBHkrXAWzlCLVg7ehOq9h8_SsBNmXyAwM8TrP9ZZ8L4Jo8ZQ X-Yahoo-Newman-Property: ymail-3 Message-ID: <492F0832.4020409@netconfcentral.com> Date: Thu, 27 Nov 2008 12:50:58 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <492ED548.20105@s3group.com> <492EDB92.9020007@netconfcentral.com> <20081127.203623.123935533.mbj@tail-f.com> In-Reply-To: <20081127.203623.123935533.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] test-option in edit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: >> The best change would be to get rid of test-option completely. > > Some implementations (including yours I believe) also allow the value > "test-only" for test-option. By using this value, you can validate an > edit-config PDU. If I understand things correctly, this was supposed > to be covered by the operation, but as we have discussed > serveral times earlier, this didn't work. So I would rather like to > see "test-only" standardized. > I agree test-option=test-only is more useful, perhaps a different use-case. The only use for the current enums would be if you wanted to force or avoid a validate on the candidate config each time you did an incremental edit-config. I don't know why that is useful, which is why Tomasz wants to change the default to 'set'. Most implementations (including mine) do not run all the 'commit-tests' on edit-config operations to candidate, since the whole point of this target is to allow incremental edits which may not be valid until all the edits are done. I'm currently implementing this default wrong for candidate, so thanks for pointing that out. You have to run explicitly to run the 'commit-tests' on candidate. I ignore test-then-set I guess. I changed my mind about removing this knob. I forgot about test-only. The default should be set, since that is the right thing for candidate, and the same as test-then-set for running. > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Nov 27 15:38:27 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 3A7C03A6B0B; Thu, 27 Nov 2008 15:38:27 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02EDD3A6B5A for ; Thu, 27 Nov 2008 15:38:26 -0800 (PST) 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 7YVpISogp1N2 for ; Thu, 27 Nov 2008 15:38:24 -0800 (PST) Received: from mailsrv.s3group.com (tales.s3group.com [193.120.90.35]) by core3.amsl.com (Postfix) with ESMTP id 43E953A6AF4 for ; Thu, 27 Nov 2008 15:38:23 -0800 (PST) Received: from exduba.dublin.ad.s3group.com (host-89-100.s3group.com [193.120.89.100] (may be forged)) by mailsrv.s3group.com with ESMTP id mARNcHIa016411; Thu, 27 Nov 2008 23:38:17 GMT Received: from webmail.s3group.com ([193.120.90.34]) by exduba.dublin.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Nov 2008 23:38:17 +0000 Received: from 87.99.34.137 (SquirrelMail authenticated user tomaszmi) by webmail.s3group.com with HTTP; Thu, 27 Nov 2008 23:38:16 -0000 (GMT) Message-ID: <22278.87.99.34.137.1227829096.squirrel@webmail.s3group.com> In-Reply-To: <492EDB92.9020007@netconfcentral.com> References: <492ED548.20105@s3group.com> <492EDB92.9020007@netconfcentral.com> Date: Thu, 27 Nov 2008 23:38:16 -0000 (GMT) From: tomaszmi@s3group.com To: "Andy Bierman" User-Agent: SquirrelMail/1.4.8-6.el3 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-OriginalArrivalTime: 27 Nov 2008 23:38:17.0051 (UTC) FILETIME=[38FD82B0:01C950E9] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (tales) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailsrv.s3group.com [193.120.90.35]); Thu, 27 Nov 2008 23:38:19 +0000 (GMT) Cc: NETCONF Subject: Re: [Netconf] test-option in edit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > Tomasz Mikolajczyk wrote: >> Hi, >> >> The RFC 4741 in section 7.2 says: >> >> "test-option: >> >> The test-option element may be specified only if the device >> advertises the :validate capability (Section 8.6). >> >> The test-option element has one of the following values: >> >> test-then-set: Perform a validation test before attempting to >> set. If validation errors occur, do not perform the >> operation. This is the default test-option. >> >> set: Perform a set without a validation test first. >> " >> >> Does it mean that the "test-option=set" value is the same as "normal" >> edit-config behavior, i.e. as without :validate capability advertised? > > yes > >> If it does, I think the "set" value should be the default one and could >> be specified in the request no matter if the :validate capability is >> advertised or not. The "test-then-set" value would be allowed to use >> only if a server supports the :validate capability. >> > > I disagree. > The default should be to do the most validation available, > not the least. So maybe the :validate capability should be mandatory. You can't use the "test-then-set" value if your server doesn't support this capability and you can't use also the "set" value in this case (even if it is not connected with the validation at all). The default value "test-then-set" means that such value is used by a server no matter if the "test-then-set" is passed or isn't passed at all. The :validate capability is optional so even if you don't use the tag, the server assumes "test-then-set" value. It makes no sense for me. > I agree that this knob should > always be accepted if the value is 'set', regardless of > the :validate capability. > > Note that YANG must, unique, and keyref validation will > probably require an agent to run its validation code > anytime the config is changed. But since the > config is never allowed to be invalid, > then there isn't much reason to have this knob at all. > The best change would be to get rid of test-option completely. > > >> Tomasz > > Andy > Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Nov 27 15:38:27 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 3A7C03A6B0B; Thu, 27 Nov 2008 15:38:27 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02EDD3A6B5A for ; Thu, 27 Nov 2008 15:38:26 -0800 (PST) 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 7YVpISogp1N2 for ; Thu, 27 Nov 2008 15:38:24 -0800 (PST) Received: from mailsrv.s3group.com (tales.s3group.com [193.120.90.35]) by core3.amsl.com (Postfix) with ESMTP id 43E953A6AF4 for ; Thu, 27 Nov 2008 15:38:23 -0800 (PST) Received: from exduba.dublin.ad.s3group.com (host-89-100.s3group.com [193.120.89.100] (may be forged)) by mailsrv.s3group.com with ESMTP id mARNcHIa016411; Thu, 27 Nov 2008 23:38:17 GMT Received: from webmail.s3group.com ([193.120.90.34]) by exduba.dublin.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Nov 2008 23:38:17 +0000 Received: from 87.99.34.137 (SquirrelMail authenticated user tomaszmi) by webmail.s3group.com with HTTP; Thu, 27 Nov 2008 23:38:16 -0000 (GMT) Message-ID: <22278.87.99.34.137.1227829096.squirrel@webmail.s3group.com> In-Reply-To: <492EDB92.9020007@netconfcentral.com> References: <492ED548.20105@s3group.com> <492EDB92.9020007@netconfcentral.com> Date: Thu, 27 Nov 2008 23:38:16 -0000 (GMT) From: tomaszmi@s3group.com To: "Andy Bierman" User-Agent: SquirrelMail/1.4.8-6.el3 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-OriginalArrivalTime: 27 Nov 2008 23:38:17.0051 (UTC) FILETIME=[38FD82B0:01C950E9] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (tales) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailsrv.s3group.com [193.120.90.35]); Thu, 27 Nov 2008 23:38:19 +0000 (GMT) Cc: NETCONF Subject: Re: [Netconf] test-option in edit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > Tomasz Mikolajczyk wrote: >> Hi, >> >> The RFC 4741 in section 7.2 says: >> >> "test-option: >> >> The test-option element may be specified only if the device >> advertises the :validate capability (Section 8.6). >> >> The test-option element has one of the following values: >> >> test-then-set: Perform a validation test before attempting to >> set. If validation errors occur, do not perform the >> operation. This is the default test-option. >> >> set: Perform a set without a validation test first. >> " >> >> Does it mean that the "test-option=set" value is the same as "normal" >> edit-config behavior, i.e. as without :validate capability advertised? > > yes > >> If it does, I think the "set" value should be the default one and could >> be specified in the request no matter if the :validate capability is >> advertised or not. The "test-then-set" value would be allowed to use >> only if a server supports the :validate capability. >> > > I disagree. > The default should be to do the most validation available, > not the least. So maybe the :validate capability should be mandatory. You can't use the "test-then-set" value if your server doesn't support this capability and you can't use also the "set" value in this case (even if it is not connected with the validation at all). The default value "test-then-set" means that such value is used by a server no matter if the "test-then-set" is passed or isn't passed at all. The :validate capability is optional so even if you don't use the tag, the server assumes "test-then-set" value. It makes no sense for me. > I agree that this knob should > always be accepted if the value is 'set', regardless of > the :validate capability. > > Note that YANG must, unique, and keyref validation will > probably require an agent to run its validation code > anytime the config is changed. But since the > config is never allowed to be invalid, > then there isn't much reason to have this knob at all. > The best change would be to get rid of test-option completely. > > >> Tomasz > > Andy > Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 00:37: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 68DC83A6A93; Fri, 28 Nov 2008 00:37:50 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BD773A6A93 for ; Fri, 28 Nov 2008 00:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.613 X-Spam-Level: X-Spam-Status: No, score=0.613 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tM6cDPl3UkKm for ; Fri, 28 Nov 2008 00:37:45 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 86DBF3A6A7C for ; Fri, 28 Nov 2008 00:37:44 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mAS8bcRT029954 for ; Fri, 28 Nov 2008 09:37:38 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 09:37:38 +0100 Message-ID: <492FAD64.6010600@s3group.com> Date: Fri, 28 Nov 2008 09:35:48 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: NETCONF X-OriginalArrivalTime: 28 Nov 2008 08:37:38.0902 (UTC) FILETIME=[92281760:01C95134] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Fri, 28 Nov 2008 09:37:39 +0100 (CET) Subject: [Netconf] :candidate vs :writable-running X-BeenThere: netconf@ietf.org X-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 read at http://www.netconfcentral.com/netconf_docs about candidate configuration that: "When ready, the manager can use the operation to activate the changes embodied in the database, and make them part of the configuration. This also clears out the database and leaves it ready for the next use." Could you point me to a relevant section in RFC 4741 that candidate has to be cleared after commit? There is also written that: "Agent platforms which support the :candidate capability usually do not also support the :writable-running capability, since mixing direct edits to would defeat the purpose of using this scratchpad database to collect and validate changes before applying them." Let's imagine the following situation. There is a simple device with configurable interfaces. The interfaces may be added/removed or their parameters can be changed (ipaddress/port/bandwidth/description etc). At the moment there is 10000 interfaces configured in the device with ids 0-9999 and an administrator have to delete instance first (id=0) and last (9999). How it should be performed according to the above quotations? I see it like this:From netconf-bounces@ietf.org Fri Nov 28 00:37: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 68DC83A6A93; Fri, 28 Nov 2008 00:37:50 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BD773A6A93 for ; Fri, 28 Nov 2008 00:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.613 X-Spam-Level: X-Spam-Status: No, score=0.613 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tM6cDPl3UkKm for ; Fri, 28 Nov 2008 00:37:45 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 86DBF3A6A7C for ; Fri, 28 Nov 2008 00:37:44 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mAS8bcRT029954 for ; Fri, 28 Nov 2008 09:37:38 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 09:37:38 +0100 Message-ID: <492FAD64.6010600@s3group.com> Date: Fri, 28 Nov 2008 09:35:48 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: NETCONF X-OriginalArrivalTime: 28 Nov 2008 08:37:38.0902 (UTC) FILETIME=[92281760:01C95134] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Fri, 28 Nov 2008 09:37:39 +0100 (CET) Subject: [Netconf] :candidate vs :writable-running X-BeenThere: netconf@ietf.org X-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 read at http://www.netconfcentral.com/netconf_docs about candidate configuration that: "When ready, the manager can use the operation to activate the changes embodied in the database, and make them part of the configuration. This also clears out the database and leaves it ready for the next use." Could you point me to a relevant section in RFC 4741 that candidate has to be cleared after commit? There is also written that: "Agent platforms which support the :candidate capability usually do not also support the :writable-running capability, since mixing direct edits to would defeat the purpose of using this scratchpad database to collect and validate changes before applying them." Let's imagine the following situation. There is a simple device with configurable interfaces. The interfaces may be added/removed or their parameters can be changed (ipaddress/port/bandwidth/description etc). At the moment there is 10000 interfaces configured in the device with ids 0-9999 and an administrator have to delete instance first (id=0) and last (9999). How it should be performed according to the above quotations? I see it like this: - l - lock candidate - lock running - copy running to candidate (whole 10000 instances!) - delete instances 0 and 9999 in the candidate - commit (copying the whole 9998 instances) - unlock running - unlock candidate Is it true of am I wrong? Another point is that RFC 4741 says that all the changes in the candidate configuration have to be committed, otherwise running must remain unchanged. What if during commit a connection with the device would be broken, for example somebody cut the cable? How are we going to tell the device that a kind of rollback have to be done? Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ock candidate - lock running - copy running to candidate (whole 10000 instances!) - delete instances 0 and 9999 in the candidate - commit (copying the whole 9998 instances) - unlock running - unlock candidate Is it true of am I wrong? Another point is that RFC 4741 says that all the changes in the candidate configuration have to be committed, otherwise running must remain unchanged. What if during commit a connection with the device would be broken, for example somebody cut the cable? How are we going to tell the device that a kind of rollback have to be done? Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 01:18: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 7D7833A6875; Fri, 28 Nov 2008 01:18:18 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFC963A6875 for ; Fri, 28 Nov 2008 01:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDuOlIdRO+ny for ; Fri, 28 Nov 2008 01:18:16 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 957A23A682F for ; Fri, 28 Nov 2008 01:18:15 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mAS9I8rD030387; Fri, 28 Nov 2008 10:18:09 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 10:18:09 +0100 Message-ID: <492FB6E8.3070302@s3group.com> Date: Fri, 28 Nov 2008 10:16:24 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: Andy Bierman References: <492ED548.20105@s3group.com> <492EDB92.9020007@netconfcentral.com> In-Reply-To: <492EDB92.9020007@netconfcentral.com> X-OriginalArrivalTime: 28 Nov 2008 09:18:09.0203 (UTC) FILETIME=[3ABA9830:01C9513A] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Fri, 28 Nov 2008 10:18:10 +0100 (CET) Cc: NETCONF Subject: Re: [Netconf] test-option in edit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: > Tomasz Mikolajczyk wrote: >> Hi, >> >> The RFC 4741 in section 7.2 says: >> >> "test-option: >> >> The test-option element may be specified only if the device >> advertises the :validate capability (Section 8.6). >> >> The test-option element has one of the following values: >> >> test-then-set: Perform a validation test before attempting to >> set. If validation errors occur, do not perform the >> operation. This is the default test-option. >> >> set: Perform a set without a validation test first. >> " >> >> Does it mean that the "test-option=set" value is the same as "normal" >> edit-config behavior, i.e. as without :validate capability advertised? > > yes > >> If it does, I think the "set" value should be the default one and could >> be specified in the request no matter if the :validate capability is >> advertised or not. The "test-then-set" value would be allowed to use >> only if a server supports the :validate capability. >> > > I disagree. > The default should be to do the most validation available, > not the least. I agree that this knob should > always be accepted if the value is 'set', regardless of > the :validate capability. > > > Note that YANG must, unique, and keyref validation will > probably require an agent to run its validation code > anytime the config is changed. But since the > config is never allowed to be invalid, > then there isn't much reason to have this knob at all. Huh! Is it not too strong assumption? At some point running configuration may be valid, however :writable-running allows to configure it directly, so bad data always might be passed. In addition running configuration may be configurable via other protocols, like CLI, snmp, etc. Moreover, many often device may have correlated parameters and setting one parameter in the device may have influence on the others, so you cannot be sure that it's always valid. > The best change would be to get rid of test-option completely. > > >> Tomasz > > Andy > Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 01:18: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 7D7833A6875; Fri, 28 Nov 2008 01:18:18 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFC963A6875 for ; Fri, 28 Nov 2008 01:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDuOlIdRO+ny for ; Fri, 28 Nov 2008 01:18:16 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 957A23A682F for ; Fri, 28 Nov 2008 01:18:15 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mAS9I8rD030387; Fri, 28 Nov 2008 10:18:09 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 10:18:09 +0100 Message-ID: <492FB6E8.3070302@s3group.com> Date: Fri, 28 Nov 2008 10:16:24 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: Andy Bierman References: <492ED548.20105@s3group.com> <492EDB92.9020007@netconfcentral.com> In-Reply-To: <492EDB92.9020007@netconfcentral.com> X-OriginalArrivalTime: 28 Nov 2008 09:18:09.0203 (UTC) FILETIME=[3ABA9830:01C9513A] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Fri, 28 Nov 2008 10:18:10 +0100 (CET) Cc: NETCONF Subject: Re: [Netconf] test-option in edit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: > Tomasz Mikolajczyk wrote: >> Hi, >> >> The RFC 4741 in section 7.2 says: >> >> "test-option: >> >> The test-option element may be specified only if the device >> advertises the :validate capability (Section 8.6). >> >> The test-option element has one of the following values: >> >> test-then-set: Perform a validation test before attempting to >> set. If validation errors occur, do not perform the >> operation. This is the default test-option. >> >> set: Perform a set without a validation test first. >> " >> >> Does it mean that the "test-option=set" value is the same as "normal" >> edit-config behavior, i.e. as without :validate capability advertised? > > yes > >> If it does, I think the "set" value should be the default one and could >> be specified in the request no matter if the :validate capability is >> advertised or not. The "test-then-set" value would be allowed to use >> only if a server supports the :validate capability. >> > > I disagree. > The default should be to do the most validation available, > not the least. I agree that this knob should > always be accepted if the value is 'set', regardless of > the :validate capability. > > > Note that YANG must, unique, and keyref validation will > probably require an agent to run its validation code > anytime the config is changed. But since the > config is never allowed to be invalid, > then there isn't much reason to have this knob at all. Huh! Is it not too strong assumption? At some point running configuration may be valid, however :writable-running allows to configure it directly, so bad data always might be passed. In addition running configuration may be configurable via other protocols, like CLI, snmp, etc. Moreover, many often device may have correlated parameters and setting one parameter in the device may have influence on the others, so you cannot be sure that it's always valid. > The best change would be to get rid of test-option completely. > > >> Tomasz > > Andy > Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 01:56:07 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 82C2C3A6879; Fri, 28 Nov 2008 01:56:07 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7047D3A6879 for ; Fri, 28 Nov 2008 01:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IdRioSasops for ; Fri, 28 Nov 2008 01:56:05 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 013933A682F for ; Fri, 28 Nov 2008 01:56:01 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KB1002H1FKZVC@szxga01-in.huawei.com> for netconf@ietf.org; Fri, 28 Nov 2008 17:55:47 +0800 (CST) Received: from huawei.com ([172.17.1.31]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KB1003JLFKZFS@szxga01-in.huawei.com> for netconf@ietf.org; Fri, 28 Nov 2008 17:55:47 +0800 (CST) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Fri, 28 Nov 2008 17:55:42 +0800 Date: Fri, 28 Nov 2008 17:55:42 +0800 From: Washam Fan To: netconf@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: zh-CN Content-disposition: inline X-Accept-Language: zh-CN Priority: normal Subject: [Netconf] global vs. partial-lock X-BeenThere: netconf@ietf.org X-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, global lock addressed failure scenarioes including outstanding changes to candidate datastore which was not addressed by partial-lock partial lock addressed faulure scenarioes including outstanding commit to running datastore wich was not addressed by global lock How do you think about them. washam ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 01:56:07 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 82C2C3A6879; Fri, 28 Nov 2008 01:56:07 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7047D3A6879 for ; Fri, 28 Nov 2008 01:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IdRioSasops for ; Fri, 28 Nov 2008 01:56:05 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 013933A682F for ; Fri, 28 Nov 2008 01:56:01 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KB1002H1FKZVC@szxga01-in.huawei.com> for netconf@ietf.org; Fri, 28 Nov 2008 17:55:47 +0800 (CST) Received: from huawei.com ([172.17.1.31]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KB1003JLFKZFS@szxga01-in.huawei.com> for netconf@ietf.org; Fri, 28 Nov 2008 17:55:47 +0800 (CST) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Fri, 28 Nov 2008 17:55:42 +0800 Date: Fri, 28 Nov 2008 17:55:42 +0800 From: Washam Fan To: netconf@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: zh-CN Content-disposition: inline X-Accept-Language: zh-CN Priority: normal Subject: [Netconf] global vs. partial-lock X-BeenThere: netconf@ietf.org X-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, global lock addressed failure scenarioes including outstanding changes to candidate datastore which was not addressed by partial-lock partial lock addressed faulure scenarioes including outstanding commit to running datastore wich was not addressed by global lock How do you think about them. washam ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 04:32: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 1F6243A6A49; Fri, 28 Nov 2008 04:32:06 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401803A698D for ; Fri, 28 Nov 2008 04:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.498 X-Spam-Level: X-Spam-Status: No, score=0.498 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Me+vnEVku+4T for ; Fri, 28 Nov 2008 04:32:03 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 103EE3A6A49 for ; Fri, 28 Nov 2008 04:32:02 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mASCVulb032491; Fri, 28 Nov 2008 13:31:56 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 13:31:57 +0100 Message-ID: <492FE453.8040601@s3group.com> Date: Fri, 28 Nov 2008 13:30:11 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: Martin Bjorklund References: <492FE015.4050004@s3group.com> In-Reply-To: <492FE015.4050004@s3group.com> X-OriginalArrivalTime: 28 Nov 2008 12:31:57.0210 (UTC) FILETIME=[4D8FA7A0:01C95155] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Fri, 28 Nov 2008 13:31:58 +0100 (CET) Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-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 Martin Bjorklund wrote: > 5. Stream the , and send inline in the > element. Like this: > > > > > > 1500 > ... > > > > > > Could not retrieve interface stats: EIO > > ... > > > ... > > > > Clients have to be prepared to parse these errors in the middle > of the stream. It is not obvious from the spec if this > is allowed or not. The XSD seems to indicate that this is not > allowed (the group "rpcResponse" could be reused inline in the > data, but it is not perfect.) > Putting rpc-errors inline in the would also mean thatFrom netconf-bounces@ietf.org Fri Nov 28 04:32: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 1F6243A6A49; Fri, 28 Nov 2008 04:32:06 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401803A698D for ; Fri, 28 Nov 2008 04:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.498 X-Spam-Level: X-Spam-Status: No, score=0.498 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Me+vnEVku+4T for ; Fri, 28 Nov 2008 04:32:03 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 103EE3A6A49 for ; Fri, 28 Nov 2008 04:32:02 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mASCVulb032491; Fri, 28 Nov 2008 13:31:56 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 13:31:57 +0100 Message-ID: <492FE453.8040601@s3group.com> Date: Fri, 28 Nov 2008 13:30:11 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: Martin Bjorklund References: <492FE015.4050004@s3group.com> In-Reply-To: <492FE015.4050004@s3group.com> X-OriginalArrivalTime: 28 Nov 2008 12:31:57.0210 (UTC) FILETIME=[4D8FA7A0:01C95155] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Fri, 28 Nov 2008 13:31:58 +0100 (CET) Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-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 Martin Bjorklund wrote: > 5. Stream the , and send inline in the > element. Like this: > > > > > > 1500 > ... > > > > > > Could not retrieve interface stats: EIO > > ... > > > ... > > > > Clients have to be prepared to parse these errors in the middle > of the stream. It is not obvious from the spec if this > is allowed or not. The XSD seems to indicate that this is not > allowed (the group "rpcResponse" could be reused inline in the > data, but it is not perfect.) > Putting rpc-errors inline in the would also mea the following request is allowed: It's an example of the namespace selection. Does it make sense? Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf n that the following request is allowed: It's an example of the namespace selection. Does it make sense? Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 07:12: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 1A31C28C101; Fri, 28 Nov 2008 07:12:55 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA01E28C101 for ; Fri, 28 Nov 2008 07:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.497 X-Spam-Level: X-Spam-Status: No, score=0.497 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSW4IJPwCVHK for ; Fri, 28 Nov 2008 07:12:53 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 908A828C0F6 for ; Fri, 28 Nov 2008 07:12:52 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mASFChR2001532 for ; Fri, 28 Nov 2008 16:12:45 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 16:12:43 +0100 Message-ID: <49300A02.5050105@s3group.com> Date: Fri, 28 Nov 2008 16:10:58 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: NETCONF X-OriginalArrivalTime: 28 Nov 2008 15:12:43.0977 (UTC) FILETIME=[C37B7B90:01C9516B] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Fri, 28 Nov 2008 16:12:47 +0100 (CET) Subject: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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, Did you consider how a NETCONF server should handle a invalid name of the XML tag. For instance how to handle a parameter called "1port" of the "interface" class that is defined in a managed device? The following hypothetical response is an invalid XML: eth0 <1port>1234 Such parameter's name is valid from the CLI point of view. It means that this kind of "dynamic-like" model may introduce limitations in the device modeling if someone wants to use NETCONF. The following "static-like" model can solve this problem: interface eth0 1port 1234 The "dynamic-like" object has limited functionality, because it can show only a dynamic data (instances and parameters with valid values) and it's hard to show another kind of data like static information about managed_object type. Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 07:12: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 1A31C28C101; Fri, 28 Nov 2008 07:12:55 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA01E28C101 for ; Fri, 28 Nov 2008 07:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.497 X-Spam-Level: X-Spam-Status: No, score=0.497 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSW4IJPwCVHK for ; Fri, 28 Nov 2008 07:12:53 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 908A828C0F6 for ; Fri, 28 Nov 2008 07:12:52 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mASFChR2001532 for ; Fri, 28 Nov 2008 16:12:45 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 16:12:43 +0100 Message-ID: <49300A02.5050105@s3group.com> Date: Fri, 28 Nov 2008 16:10:58 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: NETCONF X-OriginalArrivalTime: 28 Nov 2008 15:12:43.0977 (UTC) FILETIME=[C37B7B90:01C9516B] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Fri, 28 Nov 2008 16:12:47 +0100 (CET) Subject: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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, Did you consider how a NETCONF server should handle a invalid name of the XML tag. For instance how to handle a parameter called "1port" of the "interface" class that is defined in a managed device? The following hypothetical response is an invalid XML: eth0 <1port>1234 Such parameter's name is valid from the CLI point of view. It means that this kind of "dynamic-like" model may introduce limitations in the device modeling if someone wants to use NETCONF. The following "static-like" model can solve this problem: interface eth0 1port 1234 The "dynamic-like" object has limited functionality, because it can show only a dynamic data (instances and parameters with valid values) and it's hard to show another kind of data like static information about managed_object type. Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 07:39:54 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 2A06F28C143; Fri, 28 Nov 2008 07:39:54 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 795B328C143 for ; Fri, 28 Nov 2008 07:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.496 X-Spam-Level: X-Spam-Status: No, score=0.496 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoOhTPjccNmL for ; Fri, 28 Nov 2008 07:39:51 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 6F6AC28C13D for ; Fri, 28 Nov 2008 07:39:51 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mASFdjlh001790 for ; Fri, 28 Nov 2008 16:39:45 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 16:39:46 +0100 Message-ID: <49301058.1050609@s3group.com> Date: Fri, 28 Nov 2008 16:38:00 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: NETCONF X-OriginalArrivalTime: 28 Nov 2008 15:39:46.0394 (UTC) FILETIME=[8A84ABA0:01C9516F] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Fri, 28 Nov 2008 16:39:47 +0100 (CET) Subject: [Netconf] filtering notification streams X-BeenThere: netconf@ietf.org X-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 3.4 from the RFC 5277 shows in the XSD schema that the element MUST appear always once and the element MUST appear at least once, because NETCONF server has to define always at least "NETCONF" stream. What in your opinion a server should return as a response for the following request: ]]>]]> The above request is invalid from the schema point of view, so I wonder if the rpc-error would be appropriate. However, according to the filtering rules, not matching elements should be just skipped. Another point. The RFC says in the section 3.2.5.1: "Available event streams for the requesting session are returned in the reply containing the and elements, where the element is mandatory, and its value is unique within the scope of a NETCONF server. An empty reply is returned if there are no available event streams, due to user-specified filters on the operation." My comments to this: 1) The "replaySupport" node is also mandatory according to the schema 2) Seems that the empty reply doesn't match the schema Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 07:39:54 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 2A06F28C143; Fri, 28 Nov 2008 07:39:54 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 795B328C143 for ; Fri, 28 Nov 2008 07:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.496 X-Spam-Level: X-Spam-Status: No, score=0.496 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoOhTPjccNmL for ; Fri, 28 Nov 2008 07:39:51 -0800 (PST) Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194]) by core3.amsl.com (Postfix) with ESMTP id 6F6AC28C13D for ; Fri, 28 Nov 2008 07:39:51 -0800 (PST) Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com [192.168.88.33]) by ormo.s3group.com.pl with ESMTP id mASFdjlh001790 for ; Fri, 28 Nov 2008 16:39:45 +0100 Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 16:39:46 +0100 Message-ID: <49301058.1050609@s3group.com> Date: Fri, 28 Nov 2008 16:38:00 +0100 From: Tomasz Mikolajczyk User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: NETCONF X-OriginalArrivalTime: 28 Nov 2008 15:39:46.0394 (UTC) FILETIME=[8A84ABA0:01C9516F] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (ormo.s3group.com.pl [212.160.116.194]); Fri, 28 Nov 2008 16:39:47 +0100 (CET) Subject: [Netconf] filtering notification streams X-BeenThere: netconf@ietf.org X-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 3.4 from the RFC 5277 shows in the XSD schema that the element MUST appear always once and the element MUST appear at least once, because NETCONF server has to define always at least "NETCONF" stream. What in your opinion a server should return as a response for the following request: ]]>]]> The above request is invalid from the schema point of view, so I wonder if the rpc-error would be appropriate. However, according to the filtering rules, not matching elements should be just skipped. Another point. The RFC says in the section 3.2.5.1: "Available event streams for the requesting session are returned in the reply containing the and elements, where the element is mandatory, and its value is unique within the scope of a NETCONF server. An empty reply is returned if there are no available event streams, due to user-specified filters on the operation." My comments to this: 1) The "replaySupport" node is also mandatory according to the schema 2) Seems that the empty reply doesn't match the schema Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 08:55: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 132163A6856; Fri, 28 Nov 2008 08:55:48 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FD183A6856 for ; Fri, 28 Nov 2008 08:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.129 X-Spam-Level: X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[AWL=0.120, 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 K58hinK95tvU for ; Fri, 28 Nov 2008 08:55:46 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6627A3A67AB for ; Fri, 28 Nov 2008 08:55:46 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8E67E220FB; Fri, 28 Nov 2008 17:55:32 +0100 (CET) X-AuditID: c1b4fb3c-ae8cfbb0000015b5-62-493022846d68 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6F3FC20E9F; Fri, 28 Nov 2008 17:55:32 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 17:55:32 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 17:55:31 +0100 Message-ID: <49302283.6050603@ericsson.com> Date: Fri, 28 Nov 2008 17:55:31 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Tomasz Mikolajczyk References: <492FE015.4050004@s3group.com> <492FE453.8040601@s3group.com> In-Reply-To: <492FE453.8040601@s3group.com> X-OriginalArrivalTime: 28 Nov 2008 16:55:31.0932 (UTC) FILETIME=[1FDEB9C0:01C9517A] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-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 Hello, We have some devices for which buffering is just not possible, they don't have the memory. An 50 USD price increase could kill the product I was told. Balazs Tomasz Mikolajczyk wrote: > Martin Bjorklund wrote: > >> 5. Stream the , and send inline in the >> element. Like this: >> >> >> >> >> >> 1500 >> ... >> >> >> >> >> >> Could not retrieve interface stats: EIO >> >> ... >> >> >> ... >> >> >> >> Clients have to be prepared to parse these errors in the middle >> of the stream. It is not obvious from the spec if this >> is allowed or not. The XSD seems to indicate that this is not >> allowed (the group "rpcResponse" could be reused inline in the >> data, but it is not perfect.) >> > > Putting rpc-errors inline in the would also mean that the > following request is allowed: > > > > > > > > xmlns:netconfNS="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > It's an example of the namespace selection. Does it make sense? > > Tomasz > > > The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). > Please direct any additional queries to: communications@s3group.com. > Thank You. > _______________________________________________ > 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 Fri Nov 28 08:55: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 132163A6856; Fri, 28 Nov 2008 08:55:48 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FD183A6856 for ; Fri, 28 Nov 2008 08:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.129 X-Spam-Level: X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[AWL=0.120, 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 K58hinK95tvU for ; Fri, 28 Nov 2008 08:55:46 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6627A3A67AB for ; Fri, 28 Nov 2008 08:55:46 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8E67E220FB; Fri, 28 Nov 2008 17:55:32 +0100 (CET) X-AuditID: c1b4fb3c-ae8cfbb0000015b5-62-493022846d68 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6F3FC20E9F; Fri, 28 Nov 2008 17:55:32 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 17:55:32 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 17:55:31 +0100 Message-ID: <49302283.6050603@ericsson.com> Date: Fri, 28 Nov 2008 17:55:31 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Tomasz Mikolajczyk References: <492FE015.4050004@s3group.com> <492FE453.8040601@s3group.com> In-Reply-To: <492FE453.8040601@s3group.com> X-OriginalArrivalTime: 28 Nov 2008 16:55:31.0932 (UTC) FILETIME=[1FDEB9C0:01C9517A] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-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 Hello, We have some devices for which buffering is just not possible, they don't have the memory. An 50 USD price increase could kill the product I was told. Balazs Tomasz Mikolajczyk wrote: > Martin Bjorklund wrote: > >> 5. Stream the , and send inline in the >> element. Like this: >> >> >> >> >> >> 1500 >> ... >> >> >> >> >> >> Could not retrieve interface stats: EIO >> >> ... >> >> >> ... >> >> >> >> Clients have to be prepared to parse these errors in the middle >> of the stream. It is not obvious from the spec if this >> is allowed or not. The XSD seems to indicate that this is not >> allowed (the group "rpcResponse" could be reused inline in the >> data, but it is not perfect.) >> > > Putting rpc-errors inline in the would also mean that the > following request is allowed: > > > > > > > > xmlns:netconfNS="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > It's an example of the namespace selection. Does it make sense? > > Tomasz > > > The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). > Please direct any additional queries to: communications@s3group.com. > Thank You. > _______________________________________________ > 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 Fri Nov 28 09:55: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 BDBC33A682B; Fri, 28 Nov 2008 09:55:43 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E823A682B for ; Fri, 28 Nov 2008 09:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.076, 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 Sm0cTS5ZrjEx for ; Fri, 28 Nov 2008 09:55:42 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id E2C303A67DD for ; Fri, 28 Nov 2008 09:55:41 -0800 (PST) Received: (qmail 2160 invoked from network); 28 Nov 2008 17:55:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 28 Nov 2008 17:55:36 -0000 X-YMail-OSG: lp7hLL4VM1lQu8qkk39.6erXDPfWD0WWdfBdXMeZYnTSiC0yWPBvkgO64ZJAUhs9NxOIskL0KuUKPzAkO2lNwKI_0OsIO9vebNSHWplzEjn2ljHpFDWY6xqTralGFXgbRt9jLPUhPMF7zcBcdFTYG9Cc X-Yahoo-Newman-Property: ymail-3 Message-ID: <49303097.9010700@netconfcentral.com> Date: Fri, 28 Nov 2008 09:55:35 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Tomasz Mikolajczyk References: <492FE015.4050004@s3group.com> <492FE453.8040601@s3group.com> In-Reply-To: <492FE453.8040601@s3group.com> Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-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 Tomasz Mikolajczyk wrote: > Martin Bjorklund wrote: > >> 5. Stream the , and send inline in the >> element. Like this: >> >> >> >> >> >> 1500 >> ... >> >> >> >> >> >> Could not retrieve interface stats: EIO >> >> ... >> >> >> ... >> >> >> >> Clients have to be prepared to parse these errors in the middle >> of the stream. It is not obvious from the spec if this >> is allowed or not. The XSD seems to indicate that this is not >> allowed (the group "rpcResponse" could be reused inline in the >> data, but it is not perfect.) >> > > Putting rpc-errors inline in the would also mean that the > following request is allowed: > Any filter request possible is allowed. There is no such thing as an error in an well-formed filter request. The filter either returns data or not, but never causes an error. If there was some agent that actually stored elements somewhere in its database, then it is possible a filter could return it. However, inline generation has nothing to do with filtering, since the operation filters against the database, and inline errors are generated in the PDU, not the database. > > > > > > > xmlns:netconfNS="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > It's an example of the namespace selection. Does it make sense? > > Tomasz > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 09:55: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 BDBC33A682B; Fri, 28 Nov 2008 09:55:43 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E823A682B for ; Fri, 28 Nov 2008 09:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.076, 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 Sm0cTS5ZrjEx for ; Fri, 28 Nov 2008 09:55:42 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id E2C303A67DD for ; Fri, 28 Nov 2008 09:55:41 -0800 (PST) Received: (qmail 2160 invoked from network); 28 Nov 2008 17:55:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 28 Nov 2008 17:55:36 -0000 X-YMail-OSG: lp7hLL4VM1lQu8qkk39.6erXDPfWD0WWdfBdXMeZYnTSiC0yWPBvkgO64ZJAUhs9NxOIskL0KuUKPzAkO2lNwKI_0OsIO9vebNSHWplzEjn2ljHpFDWY6xqTralGFXgbRt9jLPUhPMF7zcBcdFTYG9Cc X-Yahoo-Newman-Property: ymail-3 Message-ID: <49303097.9010700@netconfcentral.com> Date: Fri, 28 Nov 2008 09:55:35 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Tomasz Mikolajczyk References: <492FE015.4050004@s3group.com> <492FE453.8040601@s3group.com> In-Reply-To: <492FE453.8040601@s3group.com> Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-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 Tomasz Mikolajczyk wrote: > Martin Bjorklund wrote: > >> 5. Stream the , and send inline in the >> element. Like this: >> >> >> >> >> >> 1500 >> ... >> >> >> >> >> >> Could not retrieve interface stats: EIO >> >> ... >> >> >> ... >> >> >> >> Clients have to be prepared to parse these errors in the middle >> of the stream. It is not obvious from the spec if this >> is allowed or not. The XSD seems to indicate that this is not >> allowed (the group "rpcResponse" could be reused inline in the >> data, but it is not perfect.) >> > > Putting rpc-errors inline in the would also mean that the > following request is allowed: > Any filter request possible is allowed. There is no such thing as an error in an well-formed filter request. The filter either returns data or not, but never causes an error. If there was some agent that actually stored elements somewhere in its database, then it is possible a filter could return it. However, inline generation has nothing to do with filtering, since the operation filters against the database, and inline errors are generated in the PDU, not the database. > > > > > > > xmlns:netconfNS="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > It's an example of the namespace selection. Does it make sense? > > Tomasz > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 10:52: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 65CC528C111; Fri, 28 Nov 2008 10:52:10 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B2C328C111 for ; Fri, 28 Nov 2008 10:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOh1pyjkXt7u for ; Fri, 28 Nov 2008 10:52:08 -0800 (PST) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 27F2C3A6939 for ; Fri, 28 Nov 2008 10:52:08 -0800 (PST) X-Trace: 200155070/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.150/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.150 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFACXNL0k+vGSW/2dsb2JhbABEgwA4iRnDYgeCdg X-IronPort-AV: E=Sophos;i="4.33,683,1220223600"; d="scan'208";a="200155070" X-IP-Direction: IN Received: from 1cust150.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.150]) by smtp.pipex.tiscali.co.uk with SMTP; 28 Nov 2008 18:51:57 +0000 Message-ID: <002101c95182$1bc28120$0601a8c0@allison> From: "tom.petch" To: "Bert Wijnen \(IETF\)" , "Netconf" References: <4D7EEB1103FA450A907208A7CCFACC4E@BertLaptop> Date: Fri, 28 Nov 2008 16:34:10 +0100 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 Subject: Re: [Netconf] confirm WG consensus on potential new WG work-item:notification 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 I disagree. I think that we should make more progress with YANG before starting on content. I did not express a view at Minneapolis. Tom Petch ----- Original Message ----- From: "Bert Wijnen (IETF)" To: "Netconf" Sent: Wednesday, November 26, 2008 6:56 PM Subject: [Netconf] confirm WG consensus on potential new WG work-item:notification > WG participants, > > At our NetConf Session at IETF73, the people in the room expressed strong > support for the following statements: > > - We do not want to define extensive Notification content NOW > - We just want to define content for notifications that we URGENTLY > need now (within the next year). That is one or two notifications > - Less urgent notification content we can define once the NETMOD > results become available > > The WG chairs consider this to be WG consensus. If anyone on the mailing > listFrom netconf-bounces@ietf.org Fri Nov 28 10:52: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 65CC528C111; Fri, 28 Nov 2008 10:52:10 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B2C328C111 for ; Fri, 28 Nov 2008 10:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOh1pyjkXt7u for ; Fri, 28 Nov 2008 10:52:08 -0800 (PST) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 27F2C3A6939 for ; Fri, 28 Nov 2008 10:52:08 -0800 (PST) X-Trace: 200155070/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.150/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.150 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFACXNL0k+vGSW/2dsb2JhbABEgwA4iRnDYgeCdg X-IronPort-AV: E=Sophos;i="4.33,683,1220223600"; d="scan'208";a="200155070" X-IP-Direction: IN Received: from 1cust150.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.150]) by smtp.pipex.tiscali.co.uk with SMTP; 28 Nov 2008 18:51:57 +0000 Message-ID: <002101c95182$1bc28120$0601a8c0@allison> From: "tom.petch" To: "Bert Wijnen \(IETF\)" , "Netconf" References: <4D7EEB1103FA450A907208A7CCFACC4E@BertLaptop> Date: Fri, 28 Nov 2008 16:34:10 +0100 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 Subject: Re: [Netconf] confirm WG consensus on potential new WG work-item:notification 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 I disagree. I think that we should make more progress with YANG before starting on content. I did not express a view at Minneapolis. Tom Petch ----- Original Message ----- From: "Bert Wijnen (IETF)" To: "Netconf" Sent: Wednesday, November 26, 2008 6:56 PM Subject: [Netconf] confirm WG consensus on potential new WG work-item:notification > WG participants, > > At our NetConf Session at IETF73, the people in the room expressed strong > support for the following statements: > > - We do not want to define extensive Notification content NOW > - We just want to define content for notifications that we URGENTLY > need now (within the next year). That is one or two notifications > - Less urgent notification content we can define once the NETMOD > results become available > > The WG chairs consider this to be WG consensus. If anyone on the mailing does not agree, please speak up before Dec 3rd 2008. That is one week. > We want to try and get updated charter to IESG before X-mas. > > The WG chairs do not want to consider > draft-chisholm-netconf-not-content-00.txt > as a starting point. The reason being that it wants to do much more than the > minimal approach that is expressed above. > > The WG chairs will propose/draft new charter text that we will circulate > for consensus checking. Once we have such a draft text, we will also > call for volunteers to become editors of the document. > > Bert and Mehmet > > > _______________________________________________ > 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 > list does not agree, please speak up before Dec 3rd 2008. That is one week. > We want to try and get updated charter to IESG before X-mas. > > The WG chairs do not want to consider > draft-chisholm-netconf-not-content-00.txt > as a starting point. The reason being that it wants to do much more than the > minimal approach that is expressed above. > > The WG chairs will propose/draft new charter text that we will circulate > for consensus checking. Once we have such a draft text, we will also > call for volunteers to become editors of the document. > > Bert and Mehmet > > > _______________________________________________ > 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 Fri Nov 28 11:03:52 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 4A39F28C0DE; Fri, 28 Nov 2008 11:03:52 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 942213A67A4 for ; Fri, 28 Nov 2008 11:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, 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 ZcjHrAQgbXlR for ; Fri, 28 Nov 2008 11:03:49 -0800 (PST) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 847A63A683D for ; Fri, 28 Nov 2008 11:03:49 -0800 (PST) Received: (qmail 16154 invoked from network); 28 Nov 2008 19:03:46 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 28 Nov 2008 19:03:45 -0000 X-YMail-OSG: Il_sKvoVM1mxS3.2NzR0d5MRaoRNI68am.OB1FWD_yxCwDnTBG_y8hY1djbvaJI.WQp8_Kaues7lTQFW5dpDKyYwli01QQaXICsmxpAfy0G6IxeLMA_bEtdPNawfiH1LUkbkpdV1tc04pF4kclegzhuS X-Yahoo-Newman-Property: ymail-3 Message-ID: <49304090.3030303@netconfcentral.com> Date: Fri, 28 Nov 2008 11:03:44 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Tomasz Mikolajczyk References: <492FAD64.6010600@s3group.com> In-Reply-To: <492FAD64.6010600@s3group.com> Cc: NETCONF Subject: Re: [Netconf] :candidate vs :writable-running X-BeenThere: netconf@ietf.org X-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 Tomasz Mikolajczyk wrote: > Hi, > > I read at http://www.netconfcentral.com/netconf_docs about candidate > configuration that: > > "When ready, the manager can use the operation to activate the > changes embodied in the database, and make them part of the > configuration. This also clears out the > database and leaves it ready for the next use." > > Could you point me to a relevant section in RFC 4741 that candidate has > to be cleared after commit? > I will fix that text. I really meant to say that the 'lockability' of the candidate is reestablished. As you know, a lock operation must fail if the candidate has any changes in it at all. Once a commit or discard-changes is done, the contents of candidate are conceptually equal to the running config. I will call this the 'lock-available' state instead of 'cleared', which implies 'emptied'. > There is also written that: > "Agent platforms which support the :candidate capability usually do not > also support the :writable-running capability, since mixing direct > edits to would defeat the purpose of using this scratchpad > database to collect and validate changes before applying them." > > Let's imagine the following situation. There is a simple device with > configurable interfaces. The interfaces may be added/removed or their > parameters can be changed (ipaddress/port/bandwidth/description etc). At > the moment there is 10000 interfaces configured in the device with ids > 0-9999 and an administrator have to delete instance first (id=0) and > last (9999). How it should be performed according to the above > quotations? I see it like this: > > - lock candidate > - lock running > - copy running to candidate (whole 10000 instances!) > - delete instances 0 and 9999 in the candidate > - commit (copying the whole 9998 instances) > - unlock running > - unlock candidate > > Is it true of am I wrong? This is an implementation detail. I suggest keeping track of what actually changes in the candidate, and when you apply the commit, process only those 'dirty' nodes. For YANG commit validation, with arbitrary XPath evaluation (not the mythical hard-coded implementation described in the draft), you are probably going to want to re-run all the XPath tests on the full candidate config before the commit. Of course candidate doubles the memory required to store the config database. That's why it's an optional capability. In order to properly perform an edit-config against the running config in a YANG database, you probably need to do a temp/partial copy of the running config to run all the XPath and unique tests. It may be hard to implement, but the agent is not allowed to permit changes to the running configuration which leave it in an invalid state. Period. That is a fundamental principle of the running config. YANG referential integrity tests raise the bar quite a bit, but that's by design ;-) > > Another point is that RFC 4741 says that all the changes in the > candidate configuration have to be committed, otherwise running must > remain unchanged. What if during commit a connection with the device > would be broken, for example somebody cut the cable? How are we going to > tell the device that a kind of rollback have to be done? > You mean the session is hung? If the TCP connection doesn't break, then the operator is going to need to start a new session and kill-session the old one, caused the discard-changes operation to be executed in the old session before it terminates. > Tomasz Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 11:03:52 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 4A39F28C0DE; Fri, 28 Nov 2008 11:03:52 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 942213A67A4 for ; Fri, 28 Nov 2008 11:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, 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 ZcjHrAQgbXlR for ; Fri, 28 Nov 2008 11:03:49 -0800 (PST) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 847A63A683D for ; Fri, 28 Nov 2008 11:03:49 -0800 (PST) Received: (qmail 16154 invoked from network); 28 Nov 2008 19:03:46 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 28 Nov 2008 19:03:45 -0000 X-YMail-OSG: Il_sKvoVM1mxS3.2NzR0d5MRaoRNI68am.OB1FWD_yxCwDnTBG_y8hY1djbvaJI.WQp8_Kaues7lTQFW5dpDKyYwli01QQaXICsmxpAfy0G6IxeLMA_bEtdPNawfiH1LUkbkpdV1tc04pF4kclegzhuS X-Yahoo-Newman-Property: ymail-3 Message-ID: <49304090.3030303@netconfcentral.com> Date: Fri, 28 Nov 2008 11:03:44 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Tomasz Mikolajczyk References: <492FAD64.6010600@s3group.com> In-Reply-To: <492FAD64.6010600@s3group.com> Cc: NETCONF Subject: Re: [Netconf] :candidate vs :writable-running X-BeenThere: netconf@ietf.org X-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 Tomasz Mikolajczyk wrote: > Hi, > > I read at http://www.netconfcentral.com/netconf_docs about candidate > configuration that: > > "When ready, the manager can use the operation to activate the > changes embodied in the database, and make them part of the > configuration. This also clears out the > database and leaves it ready for the next use." > > Could you point me to a relevant section in RFC 4741 that candidate has > to be cleared after commit? > I will fix that text. I really meant to say that the 'lockability' of the candidate is reestablished. As you know, a lock operation must fail if the candidate has any changes in it at all. Once a commit or discard-changes is done, the contents of candidate are conceptually equal to the running config. I will call this the 'lock-available' state instead of 'cleared', which implies 'emptied'. > There is also written that: > "Agent platforms which support the :candidate capability usually do not > also support the :writable-running capability, since mixing direct > edits to would defeat the purpose of using this scratchpad > database to collect and validate changes before applying them." > > Let's imagine the following situation. There is a simple device with > configurable interfaces. The interfaces may be added/removed or their > parameters can be changed (ipaddress/port/bandwidth/description etc). At > the moment there is 10000 interfaces configured in the device with ids > 0-9999 and an administrator have to delete instance first (id=0) and > last (9999). How it should be performed according to the above > quotations? I see it like this: > > - lock candidate > - lock running > - copy running to candidate (whole 10000 instances!) > - delete instances 0 and 9999 in the candidate > - commit (copying the whole 9998 instances) > - unlock running > - unlock candidate > > Is it true of am I wrong? This is an implementation detail. I suggest keeping track of what actually changes in the candidate, and when you apply the commit, process only those 'dirty' nodes. For YANG commit validation, with arbitrary XPath evaluation (not the mythical hard-coded implementation described in the draft), you are probably going to want to re-run all the XPath tests on the full candidate config before the commit. Of course candidate doubles the memory required to store the config database. That's why it's an optional capability. In order to properly perform an edit-config against the running config in a YANG database, you probably need to do a temp/partial copy of the running config to run all the XPath and unique tests. It may be hard to implement, but the agent is not allowed to permit changes to the running configuration which leave it in an invalid state. Period. That is a fundamental principle of the running config. YANG referential integrity tests raise the bar quite a bit, but that's by design ;-) > > Another point is that RFC 4741 says that all the changes in the > candidate configuration have to be committed, otherwise running must > remain unchanged. What if during commit a connection with the device > would be broken, for example somebody cut the cable? How are we going to > tell the device that a kind of rollback have to be done? > You mean the session is hung? If the TCP connection doesn't break, then the operator is going to need to start a new session and kill-session the old one, caused the discard-changes operation to be executed in the old session before it terminates. > Tomasz Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 12:08: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 BF82328C10A; Fri, 28 Nov 2008 12:08:21 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7FD33A683D for ; Fri, 28 Nov 2008 12:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rzpju-7RacIw for ; Fri, 28 Nov 2008 12:08:18 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id C2A0128C10A for ; Fri, 28 Nov 2008 12:08:18 -0800 (PST) Received: (qmail 65385 invoked from network); 28 Nov 2008 20:08:15 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 28 Nov 2008 20:08:14 -0000 X-YMail-OSG: VWxPkrgVM1kQat3ZCrWYfYH9uc4ZkKDFXpzQVmdCvmQaqwMudmp11auhX0nuSNTe_ooomGDKGnXO9IMzjQ675D_ax2JOWhbMJYkU3c7TppQPF_1RwnJwypOqYfTr2mJ9i_YPGOyw.t7LzBnxz62T.8FU X-Yahoo-Newman-Property: ymail-3 Message-ID: <49304FAC.8060905@netconfcentral.com> Date: Fri, 28 Nov 2008 12:08:12 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Tomasz Mikolajczyk References: <49300A02.5050105@s3group.com> In-Reply-To: <49300A02.5050105@s3group.com> Cc: NETCONF Subject: Re: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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 Tomasz Mikolajczyk wrote: > Hi, > > Did you consider how a NETCONF server should handle a invalid name of the XML tag. For instance how to handle a parameter called "1port" of the > "interface" class that is defined in a managed device? The following hypothetical response is an invalid XML: > > > > > > eth0 > <1port>1234 > > > > > > Such parameter's name is valid from the CLI point of view. It means that this kind of "dynamic-like" model may introduce limitations in the > device modeling if someone wants to use NETCONF. The following "static-like" model can solve this problem: > Using the NETCONF standard means accepting the limitations of the standard, which in this case is imposed by XML. > > > > > interface > > eth0 > From netconf-bounces@ietf.org Fri Nov 28 12:08: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 BF82328C10A; Fri, 28 Nov 2008 12:08:21 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7FD33A683D for ; Fri, 28 Nov 2008 12:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rzpju-7RacIw for ; Fri, 28 Nov 2008 12:08:18 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id C2A0128C10A for ; Fri, 28 Nov 2008 12:08:18 -0800 (PST) Received: (qmail 65385 invoked from network); 28 Nov 2008 20:08:15 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 28 Nov 2008 20:08:14 -0000 X-YMail-OSG: VWxPkrgVM1kQat3ZCrWYfYH9uc4ZkKDFXpzQVmdCvmQaqwMudmp11auhX0nuSNTe_ooomGDKGnXO9IMzjQ675D_ax2JOWhbMJYkU3c7TppQPF_1RwnJwypOqYfTr2mJ9i_YPGOyw.t7LzBnxz62T.8FU X-Yahoo-Newman-Property: ymail-3 Message-ID: <49304FAC.8060905@netconfcentral.com> Date: Fri, 28 Nov 2008 12:08:12 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Tomasz Mikolajczyk References: <49300A02.5050105@s3group.com> In-Reply-To: <49300A02.5050105@s3group.com> Cc: NETCONF Subject: Re: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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 Tomasz Mikolajczyk wrote: > Hi, > > Did you consider how a NETCONF server should handle a invalid name of the XML tag. For instance how to handle a parameter called "1port" of the > "interface" class that is defined in a managed device? The following hypothetical response is an invalid XML: > > > > > > eth0 > <1port>1234 > > > > > > Such parameter's name is valid from the CLI point of view. It means that this kind of "dynamic-like" model may introduce limitations in the > device modeling if someone wants to use NETCONF. The following "static-like" model can solve this problem: > Using the NETCONF standard means accepting the limitations of the standard, which in this case is imposed by XML. > > > > > interface > > eth0 > > 1port > 1234 > > > > > > > You could internally map the CLI name to some valid XML name, instead of this sort of double abstraction, but it is just a DM design choice. > > The "dynamic-like" object has limited functionality, because it can show only a dynamic data (instances and parameters with valid values) and > it's hard to show another kind of data like static information about managed_object type. > > Tomasz > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf > 1port > 1234 > > > > > > > You could internally map the CLI name to some valid XML name, instead of this sort of double abstraction, but it is just a DM design choice. > > The "dynamic-like" object has limited functionality, because it can show only a dynamic data (instances and parameters with valid values) and > it's hard to show another kind of data like static information about managed_object type. > > Tomasz > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 13:13: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 068DF3A69B3; Fri, 28 Nov 2008 13:13:24 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390E03A69B3 for ; Fri, 28 Nov 2008 13:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 0CKN3eVoTvlz for ; Fri, 28 Nov 2008 13:13:22 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 4744B3A67FD for ; Fri, 28 Nov 2008 13:13:22 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSTBe3PBV2LWcuJQ9wjUsAa7ndsZ6+x58@postini.com; Fri, 28 Nov 2008 13:13:19 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Fri, 28 Nov 2008 13:11:58 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Nov 2008 13:11:57 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Nov 2008 13:11:57 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Nov 2008 13:11:57 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mASLBuM34246; Fri, 28 Nov 2008 13:11:56 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id mASL6lxD073641; Fri, 28 Nov 2008 21:06:47 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200811282106.mASL6lxD073641@idle.juniper.net> To: Tomasz Mikolajczyk In-Reply-To: <49300A02.5050105@s3group.com> Date: Fri, 28 Nov 2008 16:06:46 -0500 From: Phil Shafer X-OriginalArrivalTime: 28 Nov 2008 21:11:57.0575 (UTC) FILETIME=[F26D8970:01C9519D] MIME-Version: 1.0 Cc: NETCONF Subject: Re: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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 Tomasz Mikolajczyk writes: >Did you consider how a NETCONF server should handle a invalid name of the XML >tag. Invalid XML is a protocol error. IIRC this causes the connection to be terminated. >For instance how to handle a parameter called "1port" of the >"interface" class that is defined in a managed device? In our DDL (the JUNOS DDL is more CLI oriented), we have a property called "xml-name" for translating CLI into XML. For example, the "1port" element could have an xml-name of "one-port". attribute 1port { xml-name "one-port"; ... } In YANG, this would work backwards, with your "one-port" leaf having a "cli-name" property telling the CLI the term to use: leaf one-port { my:cli-name "1port"; ... } Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 13:13: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 068DF3A69B3; Fri, 28 Nov 2008 13:13:24 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390E03A69B3 for ; Fri, 28 Nov 2008 13:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 0CKN3eVoTvlz for ; Fri, 28 Nov 2008 13:13:22 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 4744B3A67FD for ; Fri, 28 Nov 2008 13:13:22 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSTBe3PBV2LWcuJQ9wjUsAa7ndsZ6+x58@postini.com; Fri, 28 Nov 2008 13:13:19 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Fri, 28 Nov 2008 13:11:58 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Nov 2008 13:11:57 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Nov 2008 13:11:57 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Nov 2008 13:11:57 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mASLBuM34246; Fri, 28 Nov 2008 13:11:56 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id mASL6lxD073641; Fri, 28 Nov 2008 21:06:47 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200811282106.mASL6lxD073641@idle.juniper.net> To: Tomasz Mikolajczyk In-Reply-To: <49300A02.5050105@s3group.com> Date: Fri, 28 Nov 2008 16:06:46 -0500 From: Phil Shafer X-OriginalArrivalTime: 28 Nov 2008 21:11:57.0575 (UTC) FILETIME=[F26D8970:01C9519D] MIME-Version: 1.0 Cc: NETCONF Subject: Re: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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 Tomasz Mikolajczyk writes: >Did you consider how a NETCONF server should handle a invalid name of the XML >tag. Invalid XML is a protocol error. IIRC this causes the connection to be terminated. >For instance how to handle a parameter called "1port" of the >"interface" class that is defined in a managed device? In our DDL (the JUNOS DDL is more CLI oriented), we have a property called "xml-name" for translating CLI into XML. For example, the "1port" element could have an xml-name of "one-port". attribute 1port { xml-name "one-port"; ... } In YANG, this would work backwards, with your "one-port" leaf having a "cli-name" property telling the CLI the term to use: leaf one-port { my:cli-name "1port"; ... } Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 13:32: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 E26463A68E1; Fri, 28 Nov 2008 13:32:42 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3253A68E1 for ; Fri, 28 Nov 2008 13:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.073, 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 BZk1OTlWTI+W for ; Fri, 28 Nov 2008 13:32:40 -0800 (PST) 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 E21553A67FD for ; Fri, 28 Nov 2008 13:32:40 -0800 (PST) Received: (qmail 94832 invoked from network); 28 Nov 2008 21:32:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 28 Nov 2008 21:32:36 -0000 X-YMail-OSG: MKHvPZYVM1mgB7.IDsa4DqI9tg5zWIemvs5Np1PN1sceALFxPY1t6nUf5sVX6_mqZiwF_yGs7L14sCKY4RFvgFQXxkcgWNTdL8eeqvly2bj7bCcKn9XMkSdNbzS33EHnVe8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49306372.7020700@netconfcentral.com> Date: Fri, 28 Nov 2008 13:32:34 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Phil Shafer References: <200811282106.mASL6lxD073641@idle.juniper.net> In-Reply-To: <200811282106.mASL6lxD073641@idle.juniper.net> Cc: NETCONF Subject: Re: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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: > Tomasz Mikolajczyk writes: >> Did you consider how a NETCONF server should handle a invalid name of the XML >> tag. > > Invalid XML is a protocol error. IIRC this causes the connection > to be terminated. > Why not just an operation-failed error? I thought we put the SSH EOM marker in the protocol to maintain message framing and avoid dropping the session if invalid XML was received. >> For instance how to handle a parameter called "1port" of the >> "interface" class that is defined in a managed device? > > In our DDL (the JUNOS DDL is more CLI oriented), we have a property > called "xml-name" for translating CLI into XML. For example, the > "1port" element could have an xml-name of "one-port". > > attribute 1port { > xml-name "one-port"; > ... > } > > In YANG, this would work backwards, with your "one-port" leaf having > a "cli-name" property telling the CLI the term to use: > > leaf one-port { > my:cli-name "1port"; > ... > } > > Thanks, > Phil Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 13:32: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 E26463A68E1; Fri, 28 Nov 2008 13:32:42 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3253A68E1 for ; Fri, 28 Nov 2008 13:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.073, 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 BZk1OTlWTI+W for ; Fri, 28 Nov 2008 13:32:40 -0800 (PST) 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 E21553A67FD for ; Fri, 28 Nov 2008 13:32:40 -0800 (PST) Received: (qmail 94832 invoked from network); 28 Nov 2008 21:32:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 28 Nov 2008 21:32:36 -0000 X-YMail-OSG: MKHvPZYVM1mgB7.IDsa4DqI9tg5zWIemvs5Np1PN1sceALFxPY1t6nUf5sVX6_mqZiwF_yGs7L14sCKY4RFvgFQXxkcgWNTdL8eeqvly2bj7bCcKn9XMkSdNbzS33EHnVe8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49306372.7020700@netconfcentral.com> Date: Fri, 28 Nov 2008 13:32:34 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Phil Shafer References: <200811282106.mASL6lxD073641@idle.juniper.net> In-Reply-To: <200811282106.mASL6lxD073641@idle.juniper.net> Cc: NETCONF Subject: Re: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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: > Tomasz Mikolajczyk writes: >> Did you consider how a NETCONF server should handle a invalid name of the XML >> tag. > > Invalid XML is a protocol error. IIRC this causes the connection > to be terminated. > Why not just an operation-failed error? I thought we put the SSH EOM marker in the protocol to maintain message framing and avoid dropping the session if invalid XML was received. >> For instance how to handle a parameter called "1port" of the >> "interface" class that is defined in a managed device? > > In our DDL (the JUNOS DDL is more CLI oriented), we have a property > called "xml-name" for translating CLI into XML. For example, the > "1port" element could have an xml-name of "one-port". > > attribute 1port { > xml-name "one-port"; > ... > } > > In YANG, this would work backwards, with your "one-port" leaf having > a "cli-name" property telling the CLI the term to use: > > leaf one-port { > my:cli-name "1port"; > ... > } > > Thanks, > Phil Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 15:59:08 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 263AF3A6A98; Fri, 28 Nov 2008 15:59:08 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D5BA3A6A98 for ; Fri, 28 Nov 2008 15:59:07 -0800 (PST) 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 tCF0kXCDLtU7 for ; Fri, 28 Nov 2008 15:59:06 -0800 (PST) Received: from mailsrv.s3group.com (tales.s3group.com [193.120.90.35]) by core3.amsl.com (Postfix) with ESMTP id DBE163A6887 for ; Fri, 28 Nov 2008 15:59:05 -0800 (PST) Received: from exduba.dublin.ad.s3group.com (host-89-100.s3group.com [193.120.89.100] (may be forged)) by mailsrv.s3group.com with ESMTP id mASNwsPn011962; Fri, 28 Nov 2008 23:58:57 GMT Received: from webmail.s3group.com ([193.120.90.34]) by exduba.dublin.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Nov 2008 23:58:54 +0000 Received: from 87.99.34.137 (SquirrelMail authenticated user tomaszmi) by webmail.s3group.com with HTTP; Fri, 28 Nov 2008 23:58:54 -0000 (GMT) Message-ID: <6799.87.99.34.137.1227916734.squirrel@webmail.s3group.com> In-Reply-To: <49302283.6050603@ericsson.com> References: <492FE015.4050004@s3group.com> <492FE453.8040601@s3group.com> <49302283.6050603@ericsson.com> Date: Fri, 28 Nov 2008 23:58:54 -0000 (GMT) From: "Tomasz Mikolajczyk" To: "Balazs Lengyel" User-Agent: SquirrelMail/1.4.8-6.el3 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-OriginalArrivalTime: 28 Nov 2008 23:58:54.0574 (UTC) FILETIME=[450648E0:01C951B5] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (tales) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailsrv.s3group.com [193.120.90.35]); Fri, 28 Nov 2008 23:58:59 +0000 (GMT) Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-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 Hi, Balazs Lengyel wrote: > Hello, > We have some devices for which buffering is just not possible, they don't > have the memory. An > 50 USD price increase could kill the product I was told. > Balazs I also don't think such buffering is good. I'm just considering advantages and disadvantages of different possibilities. > Tomasz Mikolajczyk wrote: >> Martin Bjorklund wrote: >> >>> 5. Stream the , and send inline in the >>> element. Like this: >>> >>> >>> >>> >>> >>> 1500 >>> ... >>> >>> >>> >>> >>> >>> Could not retrieve interface stats: EIO >>> >>> ... >>> >>> >>> ... >>> >>> >>> >>> Clients have to be prepared to parse these errors in the middle >>> of the stream. It is not obvious from the spec if this >>> is allowed or not. The XSD seems to indicate that this is not >>> allowed (the group "rpcResponse" could be reused inline in the >>> data, but it is not perfect.) >>> >> >> Putting rpc-errors inline in the would also mean that the >> following request is allowed: >> >> > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> >> >> >> > xmlns:netconfNS="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> >> >> >> >> >> >> It's an example of the namespace selection. Does it make sense? >> >> Tomasz >> >> >> The information contained in this e-mail and in any attachments is >> confidential and is designated solely for the attention of the intended >> recipient(s). If you are not an intended recipient, you must not use, >> disclose, copy, distribute or retain this e-mail or any part thereof. If >> you have received this e-mail in error, please notify the sender by >> return e-mail and delete all copies of this e-mail from your computer >> system(s). >> Please direct any additional queries to: communications@s3group.com. >> Thank You. >> _______________________________________________ >> 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 > Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Nov 28 15:59:08 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 263AF3A6A98; Fri, 28 Nov 2008 15:59:08 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D5BA3A6A98 for ; Fri, 28 Nov 2008 15:59:07 -0800 (PST) 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 tCF0kXCDLtU7 for ; Fri, 28 Nov 2008 15:59:06 -0800 (PST) Received: from mailsrv.s3group.com (tales.s3group.com [193.120.90.35]) by core3.amsl.com (Postfix) with ESMTP id DBE163A6887 for ; Fri, 28 Nov 2008 15:59:05 -0800 (PST) Received: from exduba.dublin.ad.s3group.com (host-89-100.s3group.com [193.120.89.100] (may be forged)) by mailsrv.s3group.com with ESMTP id mASNwsPn011962; Fri, 28 Nov 2008 23:58:57 GMT Received: from webmail.s3group.com ([193.120.90.34]) by exduba.dublin.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Nov 2008 23:58:54 +0000 Received: from 87.99.34.137 (SquirrelMail authenticated user tomaszmi) by webmail.s3group.com with HTTP; Fri, 28 Nov 2008 23:58:54 -0000 (GMT) Message-ID: <6799.87.99.34.137.1227916734.squirrel@webmail.s3group.com> In-Reply-To: <49302283.6050603@ericsson.com> References: <492FE015.4050004@s3group.com> <492FE453.8040601@s3group.com> <49302283.6050603@ericsson.com> Date: Fri, 28 Nov 2008 23:58:54 -0000 (GMT) From: "Tomasz Mikolajczyk" To: "Balazs Lengyel" User-Agent: SquirrelMail/1.4.8-6.el3 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-OriginalArrivalTime: 28 Nov 2008 23:58:54.0574 (UTC) FILETIME=[450648E0:01C951B5] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (tales) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailsrv.s3group.com [193.120.90.35]); Fri, 28 Nov 2008 23:58:59 +0000 (GMT) Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-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 Hi, Balazs Lengyel wrote: > Hello, > We have some devices for which buffering is just not possible, they don't > have the memory. An > 50 USD price increase could kill the product I was told. > Balazs I also don't think such buffering is good. I'm just considering advantages and disadvantages of different possibilities. > Tomasz Mikolajczyk wrote: >> Martin Bjorklund wrote: >> >>> 5. Stream the , and send inline in the >>> element. Like this: >>> >>> >>> >>> >>> >>> 1500 >>> ... >>> >>> >>> >>> >>> >>> Could not retrieve interface stats: EIO >>> >>> ... >>> >>> >>> ... >>> >>> >>> >>> Clients have to be prepared to parse these errors in the middle >>> of the stream. It is not obvious from the spec if this >>> is allowed or not. The XSD seems to indicate that this is not >>> allowed (the group "rpcResponse" could be reused inline in the >>> data, but it is not perfect.) >>> >> >> Putting rpc-errors inline in the would also mean that the >> following request is allowed: >> >> > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> >> >> >> > xmlns:netconfNS="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> >> >> >> >> >> >> It's an example of the namespace selection. Does it make sense? >> >> Tomasz >> >> >> The information contained in this e-mail and in any attachments is >> confidential and is designated solely for the attention of the intended >> recipient(s). If you are not an intended recipient, you must not use, >> disclose, copy, distribute or retain this e-mail or any part thereof. If >> you have received this e-mail in error, please notify the sender by >> return e-mail and delete all copies of this e-mail from your computer >> system(s). >> Please direct any additional queries to: communications@s3group.com. >> Thank You. >> _______________________________________________ >> 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 > Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Nov 29 02:33:08 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 068CE3A697E; Sat, 29 Nov 2008 02:33:08 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3893A697E for ; Sat, 29 Nov 2008 02:33:06 -0800 (PST) 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 XdEadxW+WeCg for ; Sat, 29 Nov 2008 02:33:05 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9F0CD3A6915 for ; Sat, 29 Nov 2008 02:33:05 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 881CA76C508; Sat, 29 Nov 2008 11:33:00 +0100 (CET) Date: Sat, 29 Nov 2008 11:32:57 +0100 (CET) Message-Id: <20081129.113257.140268253.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49306372.7020700@netconfcentral.com> References: <200811282106.mASL6lxD073641@idle.juniper.net> <49306372.7020700@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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: > Phil Shafer wrote: > > Tomasz Mikolajczyk writes: > >> Did you consider how a NETCONF server should handle a invalid name of the > >> XML tag. > > Invalid XML is a protocol error. IIRC this causes the connection > > to be terminated. > > > > > Why not just an operation-failed error? > I thought we put the SSH EOM marker in the protocol > to maintain message framing and avoid dropping the > session if invalid XML was received. This would be an issue for a 4742bis... What exactly is the intention of the EOM marker? Is it for the reason Andy states, so that the server can resync if it receives broken XML? Or is it there for implementations that have a simple dispatcher so that they can split the stream into messages easier? IMO, the EOM is a mistake. It can occur in valid XML, and it's easy enough to write a primitive dispatcher for valid XML. So the only use case left is the use case that Andy mentions. But is it really a use case that needs to be supported? Why is it important for a server to resync with a client that sends invalid XML? Anyway, it's too late to change this, but I think we should at least agree on how the EOM should be handled. FWIW, my implementation uses the EOM marker to maintain message framing. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Nov 29 02:33:08 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 068CE3A697E; Sat, 29 Nov 2008 02:33:08 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3893A697E for ; Sat, 29 Nov 2008 02:33:06 -0800 (PST) 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 XdEadxW+WeCg for ; Sat, 29 Nov 2008 02:33:05 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9F0CD3A6915 for ; Sat, 29 Nov 2008 02:33:05 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 881CA76C508; Sat, 29 Nov 2008 11:33:00 +0100 (CET) Date: Sat, 29 Nov 2008 11:32:57 +0100 (CET) Message-Id: <20081129.113257.140268253.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49306372.7020700@netconfcentral.com> References: <200811282106.mASL6lxD073641@idle.juniper.net> <49306372.7020700@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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: > Phil Shafer wrote: > > Tomasz Mikolajczyk writes: > >> Did you consider how a NETCONF server should handle a invalid name of the > >> XML tag. > > Invalid XML is a protocol error. IIRC this causes the connection > > to be terminated. > > > > > Why not just an operation-failed error? > I thought we put the SSH EOM marker in the protocol > to maintain message framing and avoid dropping the > session if invalid XML was received. This would be an issue for a 4742bis... What exactly is the intention of the EOM marker? Is it for the reason Andy states, so that the server can resync if it receives broken XML? Or is it there for implementations that have a simple dispatcher so that they can split the stream into messages easier? IMO, the EOM is a mistake. It can occur in valid XML, and it's easy enough to write a primitive dispatcher for valid XML. So the only use case left is the use case that Andy mentions. But is it really a use case that needs to be supported? Why is it important for a server to resync with a client that sends invalid XML? Anyway, it's too late to change this, but I think we should at least agree on how the EOM should be handled. FWIW, my implementation uses the EOM marker to maintain message framing. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Nov 29 02:41:19 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 166C53A6A7E; Sat, 29 Nov 2008 02:41:19 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BFD93A6A7E for ; Sat, 29 Nov 2008 02:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=0.070, 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 ScZ42Xzmyv6H for ; Sat, 29 Nov 2008 02:41:16 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 72C5B3A657C for ; Sat, 29 Nov 2008 02:41:16 -0800 (PST) Received: (qmail 15281 invoked from network); 29 Nov 2008 10:41:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 29 Nov 2008 10:41:11 -0000 X-YMail-OSG: srLjZ9YVM1lFeWce3jVoV4msTbE4ZyF6L8C6uEVLQYvVnBTRPsVEVhOGP1q5pty0ZnoSCKxra1EotgaCMB7o5sBM5gTzhYU5fK51.DLgZVq1BXqkFw9Q.ROORqga_uheUaSSY5iMR4V.u5evpgkk4KdK X-Yahoo-Newman-Property: ymail-3 Message-ID: <49311C45.6000302@netconfcentral.com> Date: Sat, 29 Nov 2008 02:41:09 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <200811282106.mASL6lxD073641@idle.juniper.net> <49306372.7020700@netconfcentral.com> <20081129.113257.140268253.mbj@tail-f.com> In-Reply-To: <20081129.113257.140268253.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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: >> Phil Shafer wrote: >>> Tomasz Mikolajczyk writes: >>>> Did you consider how a NETCONF server should handle a invalid name of the >>>> XML tag. >>> Invalid XML is a protocol error. IIRC this causes the connection >>> to be terminated. >>> >> >> Why not just an operation-failed error? >> I thought we put the SSH EOM marker in the protocol >> to maintain message framing and avoid dropping the >> session if invalid XML was received. > > This would be an issue for a 4742bis... What exactly is the intention > of the EOM marker? Is it for the reason Andy states, so that the > server can resync if it receives broken XML? Or is it there for > implementations that have a simple dispatcher so that they can split > the stream into messages easier? > > IMO, the EOM is a mistake. It can occur in valid XML, and it's easy > enough to write a primitive dispatcher for valid XML. So the only use > case left is the use case that Andy mentions. But is it really a use > case that needs to be supported? Why is it important for a server to > resync with a client that sends invalid XML? > > Anyway, it's too late to change this, but I think we should at least > agree on how the EOM should be handled. > > FWIW, my implementation uses the EOM marker to maintain message > framing. > mine too... We were told at the time by the XML experts that "]]>" was not allowed to appear twice in a row in valid XML, because this is the end CDATA tag. How is it valid to include this char sequence without a preceding start CDATA tag? > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Nov 29 02:41:19 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 166C53A6A7E; Sat, 29 Nov 2008 02:41:19 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BFD93A6A7E for ; Sat, 29 Nov 2008 02:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=0.070, 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 ScZ42Xzmyv6H for ; Sat, 29 Nov 2008 02:41:16 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 72C5B3A657C for ; Sat, 29 Nov 2008 02:41:16 -0800 (PST) Received: (qmail 15281 invoked from network); 29 Nov 2008 10:41:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 29 Nov 2008 10:41:11 -0000 X-YMail-OSG: srLjZ9YVM1lFeWce3jVoV4msTbE4ZyF6L8C6uEVLQYvVnBTRPsVEVhOGP1q5pty0ZnoSCKxra1EotgaCMB7o5sBM5gTzhYU5fK51.DLgZVq1BXqkFw9Q.ROORqga_uheUaSSY5iMR4V.u5evpgkk4KdK X-Yahoo-Newman-Property: ymail-3 Message-ID: <49311C45.6000302@netconfcentral.com> Date: Sat, 29 Nov 2008 02:41:09 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <200811282106.mASL6lxD073641@idle.juniper.net> <49306372.7020700@netconfcentral.com> <20081129.113257.140268253.mbj@tail-f.com> In-Reply-To: <20081129.113257.140268253.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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: >> Phil Shafer wrote: >>> Tomasz Mikolajczyk writes: >>>> Did you consider how a NETCONF server should handle a invalid name of the >>>> XML tag. >>> Invalid XML is a protocol error. IIRC this causes the connection >>> to be terminated. >>> >> >> Why not just an operation-failed error? >> I thought we put the SSH EOM marker in the protocol >> to maintain message framing and avoid dropping the >> session if invalid XML was received. > > This would be an issue for a 4742bis... What exactly is the intention > of the EOM marker? Is it for the reason Andy states, so that the > server can resync if it receives broken XML? Or is it there for > implementations that have a simple dispatcher so that they can split > the stream into messages easier? > > IMO, the EOM is a mistake. It can occur in valid XML, and it's easy > enough to write a primitive dispatcher for valid XML. So the only use > case left is the use case that Andy mentions. But is it really a use > case that needs to be supported? Why is it important for a server to > resync with a client that sends invalid XML? > > Anyway, it's too late to change this, but I think we should at least > agree on how the EOM should be handled. > > FWIW, my implementation uses the EOM marker to maintain message > framing. > mine too... We were told at the time by the XML experts that "]]>" was not allowed to appear twice in a row in valid XML, because this is the end CDATA tag. How is it valid to include this char sequence without a preceding start CDATA tag? > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Nov 29 02:43:33 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 47A233A6A7E; Sat, 29 Nov 2008 02:43:33 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6863A6A7E for ; Sat, 29 Nov 2008 02:43:32 -0800 (PST) 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=[AWL=-0.000, 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 xYF9fwsnwa3Y for ; Sat, 29 Nov 2008 02:43:31 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id BB6FF3A657C for ; Sat, 29 Nov 2008 02:43:31 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 3E70D76C508; Sat, 29 Nov 2008 11:43:28 +0100 (CET) Date: Sat, 29 Nov 2008 11:43:23 +0100 (CET) Message-Id: <20081129.114323.85229311.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49311C45.6000302@netconfcentral.com> References: <49306372.7020700@netconfcentral.com> <20081129.113257.140268253.mbj@tail-f.com> <49311C45.6000302@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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: > We were told at the time by the XML experts that "]]>" was not > allowed to appear twice in a row in valid XML, because this > is the end CDATA tag. How is it valid to include this char sequence > without a preceding start CDATA tag? It's ok in attributes (and comments). So w/ YANG it's no big deal at all, since we don't use XML atributes. And for other DMLs we just need a CLR - don't ever use this sequence in any attribute value. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Nov 29 02:43:33 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 47A233A6A7E; Sat, 29 Nov 2008 02:43:33 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6863A6A7E for ; Sat, 29 Nov 2008 02:43:32 -0800 (PST) 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=[AWL=-0.000, 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 xYF9fwsnwa3Y for ; Sat, 29 Nov 2008 02:43:31 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id BB6FF3A657C for ; Sat, 29 Nov 2008 02:43:31 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 3E70D76C508; Sat, 29 Nov 2008 11:43:28 +0100 (CET) Date: Sat, 29 Nov 2008 11:43:23 +0100 (CET) Message-Id: <20081129.114323.85229311.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49311C45.6000302@netconfcentral.com> References: <49306372.7020700@netconfcentral.com> <20081129.113257.140268253.mbj@tail-f.com> <49311C45.6000302@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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: > We were told at the time by the XML experts that "]]>" was not > allowed to appear twice in a row in valid XML, because this > is the end CDATA tag. How is it valid to include this char sequence > without a preceding start CDATA tag? It's ok in attributes (and comments). So w/ YANG it's no big deal at all, since we don't use XML atributes. And for other DMLs we just need a CLR - don't ever use this sequence in any attribute value. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Nov 29 02: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 6A2463A6A7E; Sat, 29 Nov 2008 02:57:29 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3A0C3A6A7E for ; Sat, 29 Nov 2008 02:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTRXMPu40q6A for ; Sat, 29 Nov 2008 02:57:26 -0800 (PST) Received: from mailsrv.s3group.com (tales.s3group.com [193.120.90.35]) by core3.amsl.com (Postfix) with ESMTP id 3AA943A6AC3 for ; Sat, 29 Nov 2008 02:57:26 -0800 (PST) Received: from exduba.dublin.ad.s3group.com (host-89-100.s3group.com [193.120.89.100] (may be forged)) by mailsrv.s3group.com with ESMTP id mATAvJXb020125; Sat, 29 Nov 2008 10:57:19 GMT Received: from webmail.s3group.com ([193.120.90.34]) by exduba.dublin.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 29 Nov 2008 10:57:19 +0000 Received: from 87.99.34.137 (SquirrelMail authenticated user tomaszmi) by webmail.s3group.com with HTTP; Sat, 29 Nov 2008 10:57:19 -0000 (GMT) Message-ID: <3861.87.99.34.137.1227956239.squirrel@webmail.s3group.com> Date: Sat, 29 Nov 2008 10:57:19 -0000 (GMT) From: "Tomasz Mikolajczyk" To: "Andy Bierman" User-Agent: SquirrelMail/1.4.8-6.el3 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal References: <492FAD64.6010600@s3group.com> <49304090.3030303@netconfcentral.com> In-Reply-To: <49304090.3030303@netconfcentral.com> X-OriginalArrivalTime: 29 Nov 2008 10:57:19.0330 (UTC) FILETIME=[3FB1AC20:01C95211] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (tales) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailsrv.s3group.com [193.120.90.35]); Sat, 29 Nov 2008 10:57:21 +0000 (GMT) Cc: NETCONF Subject: Re: [Netconf] :candidate vs :writable-running X-BeenThere: netconf@ietf.org X-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: > Tomasz Mikolajczyk wrote: >> Hi, >> I read at http://www.netconfcentral.com/netconf_docs about candidate configuration that: >> "When ready, the manager can use the operation to activate the >> changes embodied in the database, and make them part of the >> configuration. This also clears out the database and leaves it ready for the next use." >> Could you point me to a relevant section in RFC 4741 that candidate has to be cleared after commit? > > I will fix that text. > I really meant to say that the 'lockability' of the > candidate is reestablished. As you know, a lock operation > must fail if the candidate has any changes in it at all. Yes, I know. Section 7.5 says that the lock must fail if "The target configuration is , it has already been modified, and these changes have not been committed or rolled back." > Once a commit or discard-changes is done, the contents > of candidate are conceptually equal to the running config. > I will call this the 'lock-available' state instead of 'cleared', which implies 'emptied'. What does it mean "conceptually equal" to the running config? Could you explain more? > >> There is also written that: >> "Agent platforms which support the :candidate capability usually do not also support the :writable-running capability, since mixing direct edits to would defeat the purpose of using this scratchpad database to collect and validate changes before applying them." Let's imagine the following situation. There is a simple device with configurable interfaces. The interfaces may be added/removed or their parameters can be changed (ipaddress/port/bandwidth/description etc). At >> the moment there is 10000 interfaces configured in the device with ids 0-9999 and an administrator have to delete instance first (id=0) and last (9999). How it should be performed according to the above >> quotations? I see it like this: >> - lock candidate >> - lock running >> - copy running to candidate (whole 10000 instances!) >> - delete instances 0 and 9999 in the candidate >> - commit (copying the whole 9998 instances) >> - unlock running >> - unlock candidate >> Is it true of am I wrong? > > > This is an implementation detail. > I suggest keeping track of what actually changes in > the candidate, and when you apply the commit, > process only those 'dirty' nodes. Consider the following scenario on a newly started device (:writable-running capability is not supported): 1) Session A: works on candidate configuration and creates 10 interfaces (0-9) 2) Session A: executes commit operation 3) Session A: after commit both configuration are "conceptually equal". At least it means that running configuration has 10 interfaces configured 4) Session A: executes close-session 5) Session B: Starts. Its purpose is to remove interface 0 from the running 6) Session B: executes on running and candidate 7) Session B: executes on a candidate and as a result the instances 0-9 appear 8) in the meantime someone came to the managed device and took off one of the interface card, let's assume this one corresponding to the interface 9 of the running configuration 9) Session B: removes an instance 0 from the candidate 10) Session B: just to check one more time executes on candidate and as a result sees interfaces 1-9 11) Session B: executes operation 12) Session B: executes running and candidate If commit operation process only 'dirty' nodes that means that after the , running configuration does not have interface 0 and 9, although candidate configuration before commit operation showed the instance 9. > For YANG commit validation, with arbitrary XPath evaluation > (not the mythical hard-coded implementation described > in the draft), you are probably going to want to > re-run all the XPath tests on the full candidate config > before the commit. > > Of course candidate doubles the memory required to store > the config database. That's why it's an optional capability. > In order to properly perform an edit-config against the > running config in a YANG database, you probably need > to do a temp/partial copy of the running config > to run all the XPath and unique tests. > > It may be hard to implement, but the agent is not > allowed to permit changes to the running configuration > which leave it in an invalid state. Period. > That is a fundamental principle of the running config. > YANG referential integrity tests raise the bar quite a bit, > but that's by design ;-) > > >> Another point is that RFC 4741 says that all the changes in the candidate configuration have to be committed, otherwise running must remain unchanged. What if during commit a connection with the device would be broken, for example somebody cut the cable? How are we going to >> tell the device that a kind of rollback have to be done? > > You mean the session is hung? > If the TCP connection doesn't break, then > the operator is going to need to start a new session > and kill-session the old one, caused the discard-changes > operation to be executed in the old session before it terminates. I mean a connection between a NETCONF server and a managed device has been broken. Broken connection between the server and managed device does not mean broken session between your NETCONF client and server. How discard-changes would be invoked if there is no connection anymore with the device? It means that device probably is in the invalid state because not all changes were committed before the connection has been broken. NETCONF cannot fake transactions on its own if the device does not support them. > >> Tomasz > > > Andy > Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Nov 29 02: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 6A2463A6A7E; Sat, 29 Nov 2008 02:57:29 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3A0C3A6A7E for ; Sat, 29 Nov 2008 02:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTRXMPu40q6A for ; Sat, 29 Nov 2008 02:57:26 -0800 (PST) Received: from mailsrv.s3group.com (tales.s3group.com [193.120.90.35]) by core3.amsl.com (Postfix) with ESMTP id 3AA943A6AC3 for ; Sat, 29 Nov 2008 02:57:26 -0800 (PST) Received: from exduba.dublin.ad.s3group.com (host-89-100.s3group.com [193.120.89.100] (may be forged)) by mailsrv.s3group.com with ESMTP id mATAvJXb020125; Sat, 29 Nov 2008 10:57:19 GMT Received: from webmail.s3group.com ([193.120.90.34]) by exduba.dublin.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 29 Nov 2008 10:57:19 +0000 Received: from 87.99.34.137 (SquirrelMail authenticated user tomaszmi) by webmail.s3group.com with HTTP; Sat, 29 Nov 2008 10:57:19 -0000 (GMT) Message-ID: <3861.87.99.34.137.1227956239.squirrel@webmail.s3group.com> Date: Sat, 29 Nov 2008 10:57:19 -0000 (GMT) From: "Tomasz Mikolajczyk" To: "Andy Bierman" User-Agent: SquirrelMail/1.4.8-6.el3 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal References: <492FAD64.6010600@s3group.com> <49304090.3030303@netconfcentral.com> In-Reply-To: <49304090.3030303@netconfcentral.com> X-OriginalArrivalTime: 29 Nov 2008 10:57:19.0330 (UTC) FILETIME=[3FB1AC20:01C95211] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (tales) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailsrv.s3group.com [193.120.90.35]); Sat, 29 Nov 2008 10:57:21 +0000 (GMT) Cc: NETCONF Subject: Re: [Netconf] :candidate vs :writable-running X-BeenThere: netconf@ietf.org X-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: > Tomasz Mikolajczyk wrote: >> Hi, >> I read at http://www.netconfcentral.com/netconf_docs about candidate configuration that: >> "When ready, the manager can use the operation to activate the >> changes embodied in the database, and make them part of the >> configuration. This also clears out the database and leaves it ready for the next use." >> Could you point me to a relevant section in RFC 4741 that candidate has to be cleared after commit? > > I will fix that text. > I really meant to say that the 'lockability' of the > candidate is reestablished. As you know, a lock operation > must fail if the candidate has any changes in it at all. Yes, I know. Section 7.5 says that the lock must fail if "The target configuration is , it has already been modified, and these changes have not been committed or rolled back." > Once a commit or discard-changes is done, the contents > of candidate are conceptually equal to the running config. > I will call this the 'lock-available' state instead of 'cleared', which implies 'emptied'. What does it mean "conceptually equal" to the running config? Could you explain more? > >> There is also written that: >> "Agent platforms which support the :candidate capability usually do not also support the :writable-running capability, since mixing direct edits to would defeat the purpose of using this scratchpad database to collect and validate changes before applying them." Let's imagine the following situation. There is a simple device with configurable interfaces. The interfaces may be added/removed or their parameters can be changed (ipaddress/port/bandwidth/description etc). At >> the moment there is 10000 interfaces configured in the device with ids 0-9999 and an administrator have to delete instance first (id=0) and last (9999). How it should be performed according to the above >> quotations? I see it like this: >> - lock candidate >> - lock running >> - copy running to candidate (whole 10000 instances!) >> - delete instances 0 and 9999 in the candidate >> - commit (copying the whole 9998 instances) >> - unlock running >> - unlock candidate >> Is it true of am I wrong? > > > This is an implementation detail. > I suggest keeping track of what actually changes in > the candidate, and when you apply the commit, > process only those 'dirty' nodes. Consider the following scenario on a newly started device (:writable-running capability is not supported): 1) Session A: works on candidate configuration and creates 10 interfaces (0-9) 2) Session A: executes commit operation 3) Session A: after commit both configuration are "conceptually equal". At least it means that running configuration has 10 interfaces configured 4) Session A: executes close-session 5) Session B: Starts. Its purpose is to remove interface 0 from the running 6) Session B: executes on running and candidate 7) Session B: executes on a candidate and as a result the instances 0-9 appear 8) in the meantime someone came to the managed device and took off one of the interface card, let's assume this one corresponding to the interface 9 of the running configuration 9) Session B: removes an instance 0 from the candidate 10) Session B: just to check one more time executes on candidate and as a result sees interfaces 1-9 11) Session B: executes operation 12) Session B: executes running and candidate If commit operation process only 'dirty' nodes that means that after the , running configuration does not have interface 0 and 9, although candidate configuration before commit operation showed the instance 9. > For YANG commit validation, with arbitrary XPath evaluation > (not the mythical hard-coded implementation described > in the draft), you are probably going to want to > re-run all the XPath tests on the full candidate config > before the commit. > > Of course candidate doubles the memory required to store > the config database. That's why it's an optional capability. > In order to properly perform an edit-config against the > running config in a YANG database, you probably need > to do a temp/partial copy of the running config > to run all the XPath and unique tests. > > It may be hard to implement, but the agent is not > allowed to permit changes to the running configuration > which leave it in an invalid state. Period. > That is a fundamental principle of the running config. > YANG referential integrity tests raise the bar quite a bit, > but that's by design ;-) > > >> Another point is that RFC 4741 says that all the changes in the candidate configuration have to be committed, otherwise running must remain unchanged. What if during commit a connection with the device would be broken, for example somebody cut the cable? How are we going to >> tell the device that a kind of rollback have to be done? > > You mean the session is hung? > If the TCP connection doesn't break, then > the operator is going to need to start a new session > and kill-session the old one, caused the discard-changes > operation to be executed in the old session before it terminates. I mean a connection between a NETCONF server and a managed device has been broken. Broken connection between the server and managed device does not mean broken session between your NETCONF client and server. How discard-changes would be invoked if there is no connection anymore with the device? It means that device probably is in the invalid state because not all changes were committed before the connection has been broken. NETCONF cannot fake transactions on its own if the device does not support them. > >> Tomasz > > > Andy > Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Nov 29 07:25: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 4137C3A6403; Sat, 29 Nov 2008 07:25:56 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA36A3A6403 for ; Sat, 29 Nov 2008 07:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.068, 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 PHPM8H1oAzQt for ; Sat, 29 Nov 2008 07:25:54 -0800 (PST) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 1CD963A63D2 for ; Sat, 29 Nov 2008 07:25:53 -0800 (PST) Received: (qmail 35709 invoked from network); 29 Nov 2008 15:25:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 29 Nov 2008 15:25:48 -0000 X-YMail-OSG: o5FiDKsVM1lTS1TlQiRxfcXFWYYX4TwRF.MFNVv3WQzgwLVUjEFPLwWnB7v957VzfpeQesnBOdO4q4nBk8A.yCUxBbpWSlq_C.ItFIUmU1fmlYGHghaZYT3a8dVteQ5lmJSr7U12Vx_L4AvtChJQHtFY X-Yahoo-Newman-Property: ymail-3 Message-ID: <49315EFA.3000406@netconfcentral.com> Date: Sat, 29 Nov 2008 07:25:46 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <49306372.7020700@netconfcentral.com> <20081129.113257.140268253.mbj@tail-f.com> <49311C45.6000302@netconfcentral.com> <20081129.114323.85229311.mbj@tail-f.com> In-Reply-To: <20081129.114323.85229311.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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: >> We were told at the time by the XML experts that "]]>" was not >> allowed to appear twice in a row in valid XML, because this >> is the end CDATA tag. How is it valid to include this char sequence >> without a preceding start CDATA tag? > > It's ok in attributes (and comments). So w/ YANG it's no big deal at > all, since we don't use XML atributes. And for other DMLs we just > need a CLR - don't ever use this sequence in any attribute value. > That is not what we were told by the XML Directorate. I don't understand how all those experts could get something so basic, so completely wrong. We have attributes in the element so we need a CLR that says "]]>]]>" is not allowed to appear anywhere inside a NETCONF PDU. > > /martin > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Nov 29 07:25: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 4137C3A6403; Sat, 29 Nov 2008 07:25:56 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA36A3A6403 for ; Sat, 29 Nov 2008 07:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.068, 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 PHPM8H1oAzQt for ; Sat, 29 Nov 2008 07:25:54 -0800 (PST) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 1CD963A63D2 for ; Sat, 29 Nov 2008 07:25:53 -0800 (PST) Received: (qmail 35709 invoked from network); 29 Nov 2008 15:25:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 29 Nov 2008 15:25:48 -0000 X-YMail-OSG: o5FiDKsVM1lTS1TlQiRxfcXFWYYX4TwRF.MFNVv3WQzgwLVUjEFPLwWnB7v957VzfpeQesnBOdO4q4nBk8A.yCUxBbpWSlq_C.ItFIUmU1fmlYGHghaZYT3a8dVteQ5lmJSr7U12Vx_L4AvtChJQHtFY X-Yahoo-Newman-Property: ymail-3 Message-ID: <49315EFA.3000406@netconfcentral.com> Date: Sat, 29 Nov 2008 07:25:46 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Martin Bjorklund References: <49306372.7020700@netconfcentral.com> <20081129.113257.140268253.mbj@tail-f.com> <49311C45.6000302@netconfcentral.com> <20081129.114323.85229311.mbj@tail-f.com> In-Reply-To: <20081129.114323.85229311.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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: >> We were told at the time by the XML experts that "]]>" was not >> allowed to appear twice in a row in valid XML, because this >> is the end CDATA tag. How is it valid to include this char sequence >> without a preceding start CDATA tag? > > It's ok in attributes (and comments). So w/ YANG it's no big deal at > all, since we don't use XML atributes. And for other DMLs we just > need a CLR - don't ever use this sequence in any attribute value. > That is not what we were told by the XML Directorate. I don't understand how all those experts could get something so basic, so completely wrong. We have attributes in the element so we need a CLR that says "]]>]]>" is not allowed to appear anywhere inside a NETCONF PDU. > > /martin > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Nov 29 08:03: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 955363A69DF; Sat, 29 Nov 2008 08:03:24 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43F233A69DF for ; Sat, 29 Nov 2008 08:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=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 K8tzjjl8v7ml for ; Sat, 29 Nov 2008 08:03:22 -0800 (PST) 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 320CE3A692B for ; Sat, 29 Nov 2008 08:03:22 -0800 (PST) Received: (qmail 9653 invoked from network); 29 Nov 2008 16:03:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 29 Nov 2008 16:03:17 -0000 X-YMail-OSG: 3Firbw4VM1lTGTZxg6brl8FzH6NYbbcthGY4YGfBr3tzbLH_D6cqlh6m6onSoH5sIXlydan_HkeSmz6TPse92Pyca9lUzQ_jRYTDLgWVfHGqarMukyFnAys93RMQpKzkI9Nmlw_jf3u8E.JuAsJhlc2p X-Yahoo-Newman-Property: ymail-3 Message-ID: <493167C3.2060502@netconfcentral.com> Date: Sat, 29 Nov 2008 08:03:15 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Tomasz Mikolajczyk References: <492FAD64.6010600@s3group.com> <49304090.3030303@netconfcentral.com> <3861.87.99.34.137.1227956239.squirrel@webmail.s3group.com> In-Reply-To: <3861.87.99.34.137.1227956239.squirrel@webmail.s3group.com> Cc: NETCONF Subject: Re: [Netconf] :candidate vs :writable-running X-BeenThere: netconf@ietf.org X-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 Tomasz Mikolajczyk wrote: > Andy Bierman wrote: >> Tomasz Mikolajczyk wrote: >>> Hi, >>> I read at http://www.netconfcentral.com/netconf_docs about candidate > configuration that: >>> "When ready, the manager can use the operation to activate > the >>> changes embodied in the database, and make them part of > the >>> configuration. This also clears out the > database and leaves it ready for the next use." >>> Could you point me to a relevant section in RFC 4741 that candidate has > to be cleared after commit? >> I will fix that text. >> I really meant to say that the 'lockability' of the >> candidate is reestablished. As you know, a lock operation >> must fail if the candidate has any changes in it at all. > > Yes, I know. Section 7.5 says that the lock must fail if "The target > configuration is , it has already been modified, and these > changes have not been committed or rolled back." > >> Once a commit or discard-changes is done, the contents >> of candidate are conceptually equal to the running config. >> I will call this the 'lock-available' state instead of 'cleared', which > implies 'emptied'. > > What does it mean "conceptually equal" to the running config? Could you > explain more? > has the same config=true nodes >>> There is also written that: >>> "Agent platforms which support the :candidate capability usually do not > also support the :writable-running capability, since mixing direct > edits to would defeat the purpose of using this scratchpad > database to collect and validate changes before applying them." Let's > imagine the following situation. There is a simple device with > configurable interfaces. The interfaces may be added/removed or their > parameters can be changed (ipaddress/port/bandwidth/description etc). > At >>> the moment there is 10000 interfaces configured in the device with ids > 0-9999 and an administrator have to delete instance first (id=0) and > last (9999). How it should be performed according to the above >>> quotations? I see it like this: >>> - lock candidate >>> - lock running >>> - copy running to candidate (whole 10000 instances!) >>> - delete instances 0 and 9999 in the candidate >>> - commit (copying the whole 9998 instances) >>> - unlock running >>> - unlock candidate >>> Is it true of am I wrong? >> >> This is an implementation detail. >> I suggest keeping track of what actually changes in >> the candidate, and when you apply the commit, >> process only those 'dirty' nodes. > > Consider the following scenario on a newly started device > (:writable-running capability is not supported): > 1) Session A: works on candidate configuration and creates 10 interfaces > (0-9) > 2) Session A: executes commit operation > 3) Session A: after commit both configuration are "conceptually equal". At > least it means that running configuration has 10 interfaces configured > 4) Session A: executes close-session > 5) Session B: Starts. Its purpose is to remove interface 0 from the running > 6) Session B: executes on running and candidate > 7) Session B: executes on a candidate and as a result the > instances 0-9 appear > 8) in the meantime someone came to the managed device and took off one of > the interface card, let's assume this one corresponding to the interface 9 > of the running configuration > 9) Session B: removes an instance 0 from the candidate > 10) Session B: just to check one more time executes on > candidate and as a result sees interfaces 1-9 > 11) Session B: executes operation > 12) Session B: executes running and candidate > > If commit operation process only 'dirty' nodes that means that after the > , running configuration does not have interface 0 and 9, although > candidate configuration before commit operation showed the instance 9. > There is a difference between the config data for an interface and the hardware card containing the interface. This problem is not NETCONF-specific at all. Whether the config data for the missing interface disappears is an implementation issue at this time. >> For YANG commit validation, with arbitrary XPath evaluation >> (not the mythical hard-coded implementation described >> in the draft), you are probably going to want to >> re-run all the XPath tests on the full candidate config >> before the commit. >> >> Of course candidate doubles the memory required to store >> the config database. That's why it's an optional capability. >> In order to properly perform an edit-config against the >> running config in a YANG database, you probably need >> to do a temp/partial copy of the running config >> to run all the XPath and unique tests. >> >> It may be hard to implement, but the agent is not >> allowed to permit changes to the running configuration >> which leave it in an invalid state. Period. >> That is a fundamental principle of the running config. >> YANG referential integrity tests raise the bar quite a bit, >> but that's by design ;-) >> >> >>> Another point is that RFC 4741 says that all the changes in the > candidate configuration have to be committed, otherwise running must > remain unchanged. What if during commit a connection with the device > would be broken, for example somebody cut the cable? How are we going > to >>> tell the device that a kind of rollback have to be done? >> You mean the session is hung? >> If the TCP connection doesn't break, then >> the operator is going to need to start a new session >> and kill-session the old one, caused the discard-changes >> operation to be executed in the old session before it terminates. > > I mean a connection between a NETCONF server and a managed device has been > broken. Broken connection between the server and managed device does not > mean broken session between your NETCONF client and server. How > discard-changes would be invoked if there is no connection anymore with > the device? It means that device probably is in the invalid state because > not all changes were committed before the connection has been broken. > NETCONF cannot fake transactions on its own if the device does not support > them. > According to the protocol, the NETCONF server is the managed device. Any back-end protocol you have is just an implementation detail to NETCONF. But if you can no longer execute any RPC operations except , you could drop the session or just return operation-failed for every request. NETCONF has no proxy and no sub-agent protocol. By design. It's complicated enough to do CM without it. >>> Tomasz >> >> Andy >> > > Tomasz > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Nov 29 08:03: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 955363A69DF; Sat, 29 Nov 2008 08:03:24 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43F233A69DF for ; Sat, 29 Nov 2008 08:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=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 K8tzjjl8v7ml for ; Sat, 29 Nov 2008 08:03:22 -0800 (PST) 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 320CE3A692B for ; Sat, 29 Nov 2008 08:03:22 -0800 (PST) Received: (qmail 9653 invoked from network); 29 Nov 2008 16:03:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.212 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 29 Nov 2008 16:03:17 -0000 X-YMail-OSG: 3Firbw4VM1lTGTZxg6brl8FzH6NYbbcthGY4YGfBr3tzbLH_D6cqlh6m6onSoH5sIXlydan_HkeSmz6TPse92Pyca9lUzQ_jRYTDLgWVfHGqarMukyFnAys93RMQpKzkI9Nmlw_jf3u8E.JuAsJhlc2p X-Yahoo-Newman-Property: ymail-3 Message-ID: <493167C3.2060502@netconfcentral.com> Date: Sat, 29 Nov 2008 08:03:15 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Tomasz Mikolajczyk References: <492FAD64.6010600@s3group.com> <49304090.3030303@netconfcentral.com> <3861.87.99.34.137.1227956239.squirrel@webmail.s3group.com> In-Reply-To: <3861.87.99.34.137.1227956239.squirrel@webmail.s3group.com> Cc: NETCONF Subject: Re: [Netconf] :candidate vs :writable-running X-BeenThere: netconf@ietf.org X-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 Tomasz Mikolajczyk wrote: > Andy Bierman wrote: >> Tomasz Mikolajczyk wrote: >>> Hi, >>> I read at http://www.netconfcentral.com/netconf_docs about candidate > configuration that: >>> "When ready, the manager can use the operation to activate > the >>> changes embodied in the database, and make them part of > the >>> configuration. This also clears out the > database and leaves it ready for the next use." >>> Could you point me to a relevant section in RFC 4741 that candidate has > to be cleared after commit? >> I will fix that text. >> I really meant to say that the 'lockability' of the >> candidate is reestablished. As you know, a lock operation >> must fail if the candidate has any changes in it at all. > > Yes, I know. Section 7.5 says that the lock must fail if "The target > configuration is , it has already been modified, and these > changes have not been committed or rolled back." > >> Once a commit or discard-changes is done, the contents >> of candidate are conceptually equal to the running config. >> I will call this the 'lock-available' state instead of 'cleared', which > implies 'emptied'. > > What does it mean "conceptually equal" to the running config? Could you > explain more? > has the same config=true nodes >>> There is also written that: >>> "Agent platforms which support the :candidate capability usually do not > also support the :writable-running capability, since mixing direct > edits to would defeat the purpose of using this scratchpad > database to collect and validate changes before applying them." Let's > imagine the following situation. There is a simple device with > configurable interfaces. The interfaces may be added/removed or their > parameters can be changed (ipaddress/port/bandwidth/description etc). > At >>> the moment there is 10000 interfaces configured in the device with ids > 0-9999 and an administrator have to delete instance first (id=0) and > last (9999). How it should be performed according to the above >>> quotations? I see it like this: >>> - lock candidate >>> - lock running >>> - copy running to candidate (whole 10000 instances!) >>> - delete instances 0 and 9999 in the candidate >>> - commit (copying the whole 9998 instances) >>> - unlock running >>> - unlock candidate >>> Is it true of am I wrong? >> >> This is an implementation detail. >> I suggest keeping track of what actually changes in >> the candidate, and when you apply the commit, >> process only those 'dirty' nodes. > > Consider the following scenario on a newly started device > (:writable-running capability is not supported): > 1) Session A: works on candidate configuration and creates 10 interfaces > (0-9) > 2) Session A: executes commit operation > 3) Session A: after commit both configuration are "conceptually equal". At > least it means that running configuration has 10 interfaces configured > 4) Session A: executes close-session > 5) Session B: Starts. Its purpose is to remove interface 0 from the running > 6) Session B: executes on running and candidate > 7) Session B: executes on a candidate and as a result the > instances 0-9 appear > 8) in the meantime someone came to the managed device and took off one of > the interface card, let's assume this one corresponding to the interface 9 > of the running configuration > 9) Session B: removes an instance 0 from the candidate > 10) Session B: just to check one more time executes on > candidate and as a result sees interfaces 1-9 > 11) Session B: executes operation > 12) Session B: executes running and candidate > > If commit operation process only 'dirty' nodes that means that after the > , running configuration does not have interface 0 and 9, although > candidate configuration before commit operation showed the instance 9. > There is a difference between the config data for an interface and the hardware card containing the interface. This problem is not NETCONF-specific at all. Whether the config data for the missing interface disappears is an implementation issue at this time. >> For YANG commit validation, with arbitrary XPath evaluation >> (not the mythical hard-coded implementation described >> in the draft), you are probably going to want to >> re-run all the XPath tests on the full candidate config >> before the commit. >> >> Of course candidate doubles the memory required to store >> the config database. That's why it's an optional capability. >> In order to properly perform an edit-config against the >> running config in a YANG database, you probably need >> to do a temp/partial copy of the running config >> to run all the XPath and unique tests. >> >> It may be hard to implement, but the agent is not >> allowed to permit changes to the running configuration >> which leave it in an invalid state. Period. >> That is a fundamental principle of the running config. >> YANG referential integrity tests raise the bar quite a bit, >> but that's by design ;-) >> >> >>> Another point is that RFC 4741 says that all the changes in the > candidate configuration have to be committed, otherwise running must > remain unchanged. What if during commit a connection with the device > would be broken, for example somebody cut the cable? How are we going > to >>> tell the device that a kind of rollback have to be done? >> You mean the session is hung? >> If the TCP connection doesn't break, then >> the operator is going to need to start a new session >> and kill-session the old one, caused the discard-changes >> operation to be executed in the old session before it terminates. > > I mean a connection between a NETCONF server and a managed device has been > broken. Broken connection between the server and managed device does not > mean broken session between your NETCONF client and server. How > discard-changes would be invoked if there is no connection anymore with > the device? It means that device probably is in the invalid state because > not all changes were committed before the connection has been broken. > NETCONF cannot fake transactions on its own if the device does not support > them. > According to the protocol, the NETCONF server is the managed device. Any back-end protocol you have is just an implementation detail to NETCONF. But if you can no longer execute any RPC operations except , you could drop the session or just return operation-failed for every request. NETCONF has no proxy and no sub-agent protocol. By design. It's complicated enough to do CM without it. >>> Tomasz >> >> Andy >> > > Tomasz > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Nov 30 10:07: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 A727728C147; Sun, 30 Nov 2008 10:07:15 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BF7028C147 for ; Sun, 30 Nov 2008 10:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=-1.744, 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 qvX8jSjaAi8p for ; Sun, 30 Nov 2008 10:07:12 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id B3E2328C113 for ; Sun, 30 Nov 2008 10:07:11 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAUI76sK022113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 30 Nov 2008 19:07:06 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAUI768j021935 for ; Sun, 30 Nov 2008 19:07:06 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.103]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Nov 2008 19:06:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C95316.5877E722" Date: Sun, 30 Nov 2008 19:06:17 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft IETF 73 Netconf Minutes Thread-Index: AclTFlbX++zhOrRyRly967/HKIALsA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 30 Nov 2008 18:06:23.0181 (UTC) FILETIME=[5AA357D0:01C95316] Subject: [Netconf] Draft IETF 73 Netconf Minutes X-BeenThere: netconf@ietf.org X-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_01C95316.5877E722 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All,=20 attached are the draft minutes for the Netconf Session at IETF 73 we compiled so far (many thanks to Simon=20 and David H. for taking notes!). <>=20 Please send us your comments by December 7.=20 Thank you.=20 Bert & Mehmet=20 ------_=_NextPart_001_01C95316.5877E722 Content-Type: text/plain; name="Draft 73 NETCONF Session Minutes_.txt" Content-Transfer-Encoding: base64 Content-Description: Draft 73 NETCONF Session Minutes_.txt Content-Disposition: attachment; filename="Draft 73 NETCONF Session Minutes_.txt" DQojIyMgUHJlbGltaW5hcnkgIyMjDQoNCk1pbnV0ZXMgb2YgdGhlIE5ldHdvcmsgQ29uZmlndXJh dGlvbiBXRyBTZXNzaW9uIGF0IHRoZSBJRVRGICM3MywgTWlubmVhcG9saXMsIE1OLCBVU0ENCk1P TkRBWSwgTm92ZW1iZXIgMTcsIDIwMDgsIDE3NDAtMTkzMCAgDQoNCldHIENoYWlyczogDQpCZFrom netconf-bounces@ietf.org Sun Nov 30 10:07: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 A727728C147; Sun, 30 Nov 2008 10:07:15 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BF7028C147 for ; Sun, 30 Nov 2008 10:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=-1.744, 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 qvX8jSjaAi8p for ; Sun, 30 Nov 2008 10:07:12 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id B3E2328C113 for ; Sun, 30 Nov 2008 10:07:11 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAUI76sK022113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 30 Nov 2008 19:07:06 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAUI768j021935 for ; Sun, 30 Nov 2008 19:07:06 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.103]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Nov 2008 19:06:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C95316.5877E722" Date: Sun, 30 Nov 2008 19:06:17 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft IETF 73 Netconf Minutes Thread-Index: AclTFlbX++zhOrRyRly967/HKIALsA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 30 Nov 2008 18:06:23.0181 (UTC) FILETIME=[5AA357D0:01C95316] Subject: [Netconf] Draft IETF 73 Netconf Minutes X-BeenThere: netconf@ietf.org X-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_01C95316.5877E722 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All,=20 attached are the draft minutes for the Netconf Session at IETF 73 we compiled so far (many thanks to Simon=20 and David H. for taking notes!). <>=20 Please send us your comments by December 7.=20 Thank you.=20 Bert & Mehmet=20 ------_=_NextPart_001_01C95316.5877E722 Content-Type: text/plain; name="Draft 73 NETCONF Session Minutes_.txt" Content-Transfer-Encoding: base64 Content-Description: Draft 73 NETCONF Session Minutes_.txt Content-Disposition: attachment; filename="Draft 73 NETCONF Session Minutes_.txt" DQojIyMgUHJlbGltaW5hcnkgIyMjDQoNCk1pbnV0ZXMgb2YgdGhlIE5ldHdvcmsgQ29uZmlndXJh dGlvbiBXRyBTZXNzaW9uIGF0IHRoZSBJRVRGICM3MywgTWlubmVhcG9saXMsIE1OLCBVU0ENCk1P TkRBWSwgTm92ZW1iZXIgMTcsIDIwMDgsIDE3NDAtMTkzMCAgDQoNCldHIENoYWlyczoXJ0 IFdpam5lbiA8YmVydGlldGZAYndpam5lbi5uZXQ+IA0KTWVobWV0IEVyc3VlIDxtZWhtZXQuZXJz dWVAbnNuLmNvbT4gDQpBRDogRGFuIFJvbWFzY2FudQ0KDQoNCk1hbnkgVGhhbmtzIHRvIHRoZSAN Cm1pbnV0ZSB0YWtlcnM6IFNpbW9uIExlaW5lbiwgRGF2aWQgSGFycmluZ3RvbiANCmFuZCB0aGUg amFiYmVyIHNjcmliZTogRGF2aWQgUGFydGFpbg0KDQoNClRoZXJlIHdlcmUgYXBwcm94LiA0NSBw ZXJzb25zIGluIHRoZSBORVRDT05GIHNlc3Npb24uDQoNCldHIHN0YXR1cyByZXZpZXcgaGFzIGJl ZW4gZ2l2ZW4gYnkgTWVobWV0IEVyc3VlLg0KDQpBZ2VuZGEgYW5kIHN0YXR1cyBzbGlkZXM6IGh0 dHA6Ly93d3czLmlldGYub3JnL3Byb2NlZWRpbmdzLzA4bm92L3NsaWRlcy9uZXRjb25mLTYucHB0 DQoNClRoZXJlIHdlcmUgdHdvIGxhc3QgY2FsbHMgZm9yIHRoZSBQYXJ0aWFsIExvY2tpbmcgZHJh ZnQsIHBlbmRpbmcgc29tZSBlZGl0b3JpYWwgY2hhbmdlcy4gQ2FuIGdvIHRvIElFU0c/DQpORVRD T05GIG92ZXIgVExTIGluIEFEIGV2YWx1YXRpb24NCkxhc3QgQ2FsbCBmb3IgbmV0Y29uZi1tb25p dG9yaW5nIHdpbGwgYmUgZG9uZSBzb29uDQpOb3QgeWV0IGNoYXJ0ZXJlZDogIA0KNDc0MWJpczog TWFydGluIEJqb2Vya2x1bmQgYW5kIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBoYXZlIHZvbHVudGVl cmVkIGFzIGVkaXRvcnMNCndpdGgtZGVmYXVsdHMgY2FwYWJpbGl0eTogQmFsYXN6IExlbmd5ZWwg JiBBbmR5IEJpZXJtYW4NCk5vdGlmaWNhdGlvbiBjb250ZW50IGRyYWZ0OiBJdHMgZm9jdXMgYW5k IGEgcG9zc2libGUgY2hhcnRlciB1cGRhdGUgdG8gYmUgZGlzY3Vzc2VkIGluIHRoZSBzZXNzaW9u DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KTkVUQ09ORiBNb25pdG9yaW5nIFNjaGVtYSAoTWFyayBTY290 dCkNCmRyYWZ0LWlldGYtbmV0Y29uZi1tb25pdG9yaW5nLXNjaGVtYS0wMw0KDQpTbGlkZXM6IGh0 dHA6Ly93d3czLmlldGYub3JnL3Byb2NlZWRpbmdzLzA4bm92L3NsaWRlcy9uZXRjb25mLTcucHB0 DQoNCk5ldyB2ZXJzaW9uIGFkZHJlc3NlcyBhY3Rpb24gcG9pbnRzIGZyb20gSUVURiA3Mg0KLSBj bGFyaWZpZWQgdGVybWlub2xvZ3kNCi0gYXMgd2VsbCBhcyBpbmNvcnBvcmF0aW5nIG1hbnkgY29t bWVudHMgZnJvbSBtYWlsaW5nIGxpc3QNCg0KT3BlbiBpc3N1ZTogZGF0YSB0eXBlcyBkaXNjdXNz aW9uIGlzIHN0aWxsIG9uZ29pbmcsIGN1cnJlbnQgSS1EIGRlZmluZXMgaXBBZGRyZXNzIGFuZCBo b3N0TmFtZQ0KDQpQb3NzaWJsZSB3YXlzIGZvcndhcmQ6DQpBKSBkZWxheSB3b3JrIHVudGlsIG5l dG1vZCBkYXRhIHR5cGUgd29yayBjb21wbGV0ZXMNCiAgICAtIHRvIGFsaWduIGRhdGEgdHlwZXMg YW5kIHRvIGVuc3VyZSB0aGUgcmV0cmlldmFsIG1lY2hhbmlzbSBjb3ZlcnMgYWxsIG5ldG1vZCBy ZXF1aXJlbWVudHMgKG5hbWluZyBldGMuKQ0KQikgcHJvY2VlZCB3aXRoIGN1cnJlbnQgZGVmaW5p dGlvbnM/DQoNCk5leHQgc3RlcHM6DQotIHJldmlldyAtMDMgKG5vIGZlZWRiYWNrIHJlY2VpdmVk IHNvIGZhcikNCi0gY29udGludWVkIGRpc2N1c3Npb24gb24gZGF0YSB0eXBlIGlzc3VlLg0KDQpC ZXJ0IFdpam5lbjogSGFzIGJlZW4gYmVhdGluZyB1cCBvbiBNYXJrIHRvIHN0YXJ0IG9mZmxpbmUg ZGlzY3Vzc2lvbiB0byBjb21lIHVwIHdpdGggcHJvcyBhbmQgY29ucyBvZiB0aGUgdmFyaW91cyBh bHRlcm5hdGl2ZXMuICANCk1hcmsgaGFzIHRha2VuIHNvbWUgaW5pdGlhdGl2ZSwgYnV0IG90aGVy d2lzZSB0aGVyZSBoYXNuJ3QgYmVlbiBtdWNoIHZpc2libGUgZWZmb3J0LiAgV2UgbXVzdCBoYXZl IHRoaXMgZGlzY3Vzc2lvbi4gIA0KQmVydCB3YXJucyB0aGF0IGl0IGlzIG5vdCBhY2NlcHRhYmxl IHRvIGp1c3Qgbm90IHJlYWN0IHRvIGNhbGxzIGZvciBmZWVkYmFjay4gIE1hcmsncyBwcm9wb3Nh bCBmb3IgcG9zc2libGUgd2F5cyBmb3J3YXJkIGlzIGFuIGFjY2VwdGFibGUgcHJvcG9zYWwuDQpE YXZpZCBIYXJyaW5ndG9uIGhhcyB0aGUgaW1wcmVzc2lvbiB0aGF0IHRoaXMgZGlzY3Vzc2lvbiBk aWQgaGFwcGVuLg0KTWFyayBhZ3JlZXMgdGhhdCB0aGUgbmV0Y29uZi1zcGVjaWZpYyBkYXRhdHlw ZXMgaGF2ZSBiZWVuIGFsaWduZWQgd2l0aCBjdXJyZW50IG5ldG1vZCB3b3JrIG9uIHRoZSBtYWls aW5nIGxpc3QuDQpCZXJ0IGFza3MgTWFyayB0byBkb2N1bWVudCB0aGF0IGRpc2N1c3Npb24gYW5k IGl0cyBvdXRjb21lIGFuZCBwb3N0IHRoYXQgdG8gdGhlIG1haWxpbmcgbGlzdC4NCkRhdmlkIEhh cnJpbmd0b24gYWRkcyB0aGF0IHRoZSBvdXRjb21lIHdhcyB0byBub3QgdG8gdHJ5IHRvIGRvIElF VEYtd2lkZSBkYXRhIHR5cGVzLCBvbmx5IHdoYXQncyByZXF1aXJlZCBmb3IgTkVUQ09ORi4NCkJh bGFzeiB0aGlua3MgdGhlcmUgd2lsbCBoYXZlIHRvIGJlIHNvbWUgc21hbGwgY2hhbmdlcw0KSnVl cmdlbjogVGhlIGJpZ2dlc3QgaXNzdWUgaXMgY2Fub25pY2FsaXphdGlvbiBvZiBkYXRhIHR5cGVz IHdoZXJlIG11bHRpcGxlIHJlcHJlc2VudGF0aW9ucyBvZiBhIGdpdmVuIHZhbHVlIGFyZSBhbGxv d2VkLg0KTWFyayBhZ3JlZXMuDQpNYXJ0aW4gQmpvZXJrbHVuZDogV2hhdCB3ZSBwdWJsaXNoIG5v dyBtYXkgYmUgc3VmZmljaWVudCBmb3IgbW9uaXRvcmluZywgYnV0IG5vdCBuZWNlc3NhcmlseSBm b3IgY29uZmlndXJhdGlvbi4NCk1hcmsgYWdyZWVzLiAgaXBaZGRyZXNzIGluIHRoZSBkcmFmdCBp cyBvbmx5IHVzZWQgdG8gaWRlbnRpZnkgY29ubmVjdGlvbnMuICBIZSBjb3VsZCBwdW50IG9uIHRo aXMgaXNzdWUgYnkgY2hhbmdpbmcgdG8gc29tZXRoaW5nIGxpa2UgJ2Nvbm5lY3Rpb25JZCcsIGJ1 dCB3YW50ZWQgdG8ga2VlcCB0aGUgYWRkcmVzcyBzZW1hbnRpY3MuDQpNYXJ0aW46IHNvIHRoZSBj dXJyZW50IHNjb3BlIG1heSBiZSBldmVuIG5hcnJvd2VyIHRoYW4gIm5ldGNvbmYtc3BlY2lmaWMi Lg0KQmVydDogDQpCZXJ0 IFdpam5lbiA8YmVydGlldGZAYndpam5lbi5uZXQ+IA0KTWVobWV0IEVyc3VlIDxtZWhtZXQuZXJz dWVAbnNuLmNvbT4gDQpBRDogRGFuIFJvbWFzY2FudQ0KDQoNCk1hbnkgVGhhbmtzIHRvIHRoZSAN Cm1pbnV0ZSB0YWtlcnM6IFNpbW9uIExlaW5lbiwgRGF2aWQgSGFycmluZ3RvbiANCmFuZCB0aGUg amFiYmVyIHNjcmliZTogRGF2aWQgUGFydGFpbg0KDQoNClRoZXJlIHdlcmUgYXBwcm94LiA0NSBw ZXJzb25zIGluIHRoZSBORVRDT05GIHNlc3Npb24uDQoNCldHIHN0YXR1cyByZXZpZXcgaGFzIGJl ZW4gZ2l2ZW4gYnkgTWVobWV0IEVyc3VlLg0KDQpBZ2VuZGEgYW5kIHN0YXR1cyBzbGlkZXM6IGh0 dHA6Ly93d3czLmlldGYub3JnL3Byb2NlZWRpbmdzLzA4bm92L3NsaWRlcy9uZXRjb25mLTYucHB0 DQoNClRoZXJlIHdlcmUgdHdvIGxhc3QgY2FsbHMgZm9yIHRoZSBQYXJ0aWFsIExvY2tpbmcgZHJh ZnQsIHBlbmRpbmcgc29tZSBlZGl0b3JpYWwgY2hhbmdlcy4gQ2FuIGdvIHRvIElFU0c/DQpORVRD T05GIG92ZXIgVExTIGluIEFEIGV2YWx1YXRpb24NCkxhc3QgQ2FsbCBmb3IgbmV0Y29uZi1tb25p dG9yaW5nIHdpbGwgYmUgZG9uZSBzb29uDQpOb3QgeWV0IGNoYXJ0ZXJlZDogIA0KNDc0MWJpczog TWFydGluIEJqb2Vya2x1bmQgYW5kIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBoYXZlIHZvbHVudGVl cmVkIGFzIGVkaXRvcnMNCndpdGgtZGVmYXVsdHMgY2FwYWJpbGl0eTogQmFsYXN6IExlbmd5ZWwg JiBBbmR5IEJpZXJtYW4NCk5vdGlmaWNhdGlvbiBjb250ZW50IGRyYWZ0OiBJdHMgZm9jdXMgYW5k IGEgcG9zc2libGUgY2hhcnRlciB1cGRhdGUgdG8gYmUgZGlzY3Vzc2VkIGluIHRoZSBzZXNzaW9u DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KTkVUQ09ORiBNb25pdG9yaW5nIFNjaGVtYSAoTWFyayBTY290 dCkNCmRyYWZ0LWlldGYtbmV0Y29uZi1tb25pdG9yaW5nLXNjaGVtYS0wMw0KDQpTbGlkZXM6IGh0 dHA6Ly93d3czLmlldGYub3JnL3Byb2NlZWRpbmdzLzA4bm92L3NsaWRlcy9uZXRjb25mLTcucHB0 DQoNCk5ldyB2ZXJzaW9uIGFkZHJlc3NlcyBhY3Rpb24gcG9pbnRzIGZyb20gSUVURiA3Mg0KLSBj bGFyaWZpZWQgdGVybWlub2xvZ3kNCi0gYXMgd2VsbCBhcyBpbmNvcnBvcmF0aW5nIG1hbnkgY29t bWVudHMgZnJvbSBtYWlsaW5nIGxpc3QNCg0KT3BlbiBpc3N1ZTogZGF0YSB0eXBlcyBkaXNjdXNz aW9uIGlzIHN0aWxsIG9uZ29pbmcsIGN1cnJlbnQgSS1EIGRlZmluZXMgaXBBZGRyZXNzIGFuZCBo b3N0TmFtZQ0KDQpQb3NzaWJsZSB3YXlzIGZvcndhcmQ6DQpBKSBkZWxheSB3b3JrIHVudGlsIG5l dG1vZCBkYXRhIHR5cGUgd29yayBjb21wbGV0ZXMNCiAgICAtIHRvIGFsaWduIGRhdGEgdHlwZXMg YW5kIHRvIGVuc3VyZSB0aGUgcmV0cmlldmFsIG1lY2hhbmlzbSBjb3ZlcnMgYWxsIG5ldG1vZCBy ZXF1aXJlbWVudHMgKG5hbWluZyBldGMuKQ0KQikgcHJvY2VlZCB3aXRoIGN1cnJlbnQgZGVmaW5p dGlvbnM/DQoNCk5leHQgc3RlcHM6DQotIHJldmlldyAtMDMgKG5vIGZlZWRiYWNrIHJlY2VpdmVk IHNvIGZhcikNCi0gY29udGludWVkIGRpc2N1c3Npb24gb24gZGF0YSB0eXBlIGlzc3VlLg0KDQpC ZXJ0IFdpam5lbjogSGFzIGJlZW4gYmVhdGluZyB1cCBvbiBNYXJrIHRvIHN0YXJ0IG9mZmxpbmUg ZGlzY3Vzc2lvbiB0byBjb21lIHVwIHdpdGggcHJvcyBhbmQgY29ucyBvZiB0aGUgdmFyaW91cyBh bHRlcm5hdGl2ZXMuICANCk1hcmsgaGFzIHRha2VuIHNvbWUgaW5pdGlhdGl2ZSwgYnV0IG90aGVy d2lzZSB0aGVyZSBoYXNuJ3QgYmVlbiBtdWNoIHZpc2libGUgZWZmb3J0LiAgV2UgbXVzdCBoYXZl IHRoaXMgZGlzY3Vzc2lvbi4gIA0KQmVydCB3YXJucyB0aGF0IGl0IGlzIG5vdCBhY2NlcHRhYmxl IHRvIGp1c3Qgbm90IHJlYWN0IHRvIGNhbGxzIGZvciBmZWVkYmFjay4gIE1hcmsncyBwcm9wb3Nh bCBmb3IgcG9zc2libGUgd2F5cyBmb3J3YXJkIGlzIGFuIGFjY2VwdGFibGUgcHJvcG9zYWwuDQpE YXZpZCBIYXJyaW5ndG9uIGhhcyB0aGUgaW1wcmVzc2lvbiB0aGF0IHRoaXMgZGlzY3Vzc2lvbiBk aWQgaGFwcGVuLg0KTWFyayBhZ3JlZXMgdGhhdCB0aGUgbmV0Y29uZi1zcGVjaWZpYyBkYXRhdHlw ZXMgaGF2ZSBiZWVuIGFsaWduZWQgd2l0aCBjdXJyZW50IG5ldG1vZCB3b3JrIG9uIHRoZSBtYWls aW5nIGxpc3QuDQpCZXJ0IGFza3MgTWFyayB0byBkb2N1bWVudCB0aGF0IGRpc2N1c3Npb24gYW5k IGl0cyBvdXRjb21lIGFuZCBwb3N0IHRoYXQgdG8gdGhlIG1haWxpbmcgbGlzdC4NCkRhdmlkIEhh cnJpbmd0b24gYWRkcyB0aGF0IHRoZSBvdXRjb21lIHdhcyB0byBub3QgdG8gdHJ5IHRvIGRvIElF VEYtd2lkZSBkYXRhIHR5cGVzLCBvbmx5IHdoYXQncyByZXF1aXJlZCBmb3IgTkVUQ09ORi4NCkJh bGFzeiB0aGlua3MgdGhlcmUgd2lsbCBoYXZlIHRvIGJlIHNvbWUgc21hbGwgY2hhbmdlcw0KSnVl cmdlbjogVGhlIGJpZ2dlc3QgaXNzdWUgaXMgY2Fub25pY2FsaXphdGlvbiBvZiBkYXRhIHR5cGVz IHdoZXJlIG11bHRpcGxlIHJlcHJlc2VudGF0aW9ucyBvZiBhIGdpdmVuIHZhbHVlIGFyZSBhbGxv d2VkLg0KTWFyayBhZ3JlZXMuDQpNYXJ0aW4gQmpvZXJrbHVuZDogV2hhdCB3ZSBwdWJsaXNoIG5v dyBtYXkgYmUgc3VmZmljaWVudCBmb3IgbW9uaXRvcmluZywgYnV0IG5vdCBuZWNlc3NhcmlseSBm b3IgY29uZmlndXJhdGlvbi4NCk1hcmsgYWdyZWVzLiAgaXBaZGRyZXNzIGluIHRoZSBkcmFmdCBp cyBvbmx5IHVzZWQgdG8gaWRlbnRpZnkgY29ubmVjdGlvbnMuICBIZSBjb3VsZCBwdW50IG9uIHRo aXMgaXNzdWUgYnkgY2hhbmdpbmcgdG8gc29tZXRoaW5nIGxpa2UgJ2Nvbm5lY3Rpb25JZCcsIGJ1 dCB3YW50ZWQgdG8ga2VlcCB0aGUgYWRkcmVzcyBzZW1hbnRpY3MuDQpNYXJ0aW46IHNvIHRoZSBj dXJyZW50IHNjb3BlIG1heSBiZSBldmVuIG5hcnJvd2VyIHRoYW4gIm5ldGNvbmYtc3BlY2lmaWMi Lg0KQgU2hvdWxkIHdlIGRlZmVyIGdlbmVyYWxpemF0aW9uIHRvIG5ldG1vZCB3b3JrPw0K TWFyazogeWVzLiAgQWxsIHNpbWlsYXIgZGF0YSB0eXBlIGRlZmluaXRpb24gYXR0ZW1wdHMgd291 bGQgcnVuIGludG8gdGhlIHNhbWUgcHJvYmxlbS4NCkJlcnQ6IFdlIG1heSBuZWVkIHRvIGFkZCBj b21tZW50IHRvIGFsbCBkYXRhIG1vZGVscyB0aGF0IHRoZXkgbWlnaHQgY2hhbmdlLg0KQmVydDog QW55IG9iamVjdGlvbnM/IENvbnNlbnN1cyBkZWNsYXJlZC4NCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpQ YXJ0aWFsIExvY2sgUlBDIGZvciBORVRDT05GIChCYWxhenMgTGVuZ3llbCkNCmRyYWZ0LWlldGYt bmV0Y29uZi1wYXJ0aWFsLWxvY2stMDQNCg0KU2xpZGVzOiBodHRwOi8vd3d3My5pZXRmLm9yZy9w cm9jZWVkaW5ncy8wOG5vdi9zbGlkZXMvbmV0Y29uZi0xLnBwdA0KDQpHb3QgZ29vZCBjb21tZW50 cyBmcm9tIFdHTEMsIG1vc3RseSBjbGFyaWZpY2F0aW9ucywgaW1wcm92ZW1lbnRzLg0KDQoNClN1 YnN0YW50aWFsIGNoYW5nZXM6DQotIGFkZGVkIGxpc3Qgb2YgbG9ja2VkLW5vZGVzIHRvIHRoZSBv dXRwdXQgb2YgcGFydGlhbC1sb2NrIHRvIGNsYXJpZnkgd2hhdCBpcyBhY3R1YWxseSBsb2NrZWQg YXMgYSByZXN1bHQgb2Ygc29tZXdoYXQgY29tcGxleCBYUGF0aCBzZWxlY3Rpb24NCi0gYWxsb3dl ZCBhdG9taWMgbG9ja2luZyAoaW4gb25lIG9wZXJhdGlvbikgb2YgZGF0YXN0b3JlIHBhcnRzIGlu IG11bHRpcGxlIGRhdGFzdG9yZXMNCg0KTW9yZSByZWNlbnQgY29tbWVudHMgZnJvbSBQaGlsIFNo YWZlciwgd2hvIGNhbm5vdCBiZSBpbiB0aGUgc2Vzc2lvbiB0b2RheS4gRWRpdG9yaWFsIGNvbW1l bnRzIGFjY2VwdGVkLCBvdGhlcnMgbmVlZCB0byBiZSBkaXNjdXNzZWQgd2l0aCBoaW0uDQoNCkhv dyBzaG91bGQgdGhlIFlBTkcgbW9kdWxlcyBiZSBuYW1lZCBpbiB0aGUgZnV0dXJlPyBTaG91bGQg dGhleSBoYXZlIGEgcHJlZml4IGlldGYtPw0KQmFsYXN6IHRoaW5rcyB0aGlzIHNob3VsZCBiZSBq dXN0ICdwYXJ0aWFsLWxvY2tpbmcnOyBldmVyeWJvZHkgZWxzZSBjYW4gdXNlIHByZWZpeCwgaWV0 ZiBzaG91bGRuJ3QgbmVlZCB0by4NCg0KUHJvcG9zYWw6IEV4dGVuZCBnbG9iYWwgPGxvY2s+IG9w ZXJhdGlvbiByYXRoZXIgdGhhbiBpbnZlbnRpbmcgbmV3IG9wZXJhdGlvbg0KQmFsYXpzIHByb3Bv c2VzIHRvIHJlamVjdCB0aGlzOg0KLSBnbG9iYWwgPGxvY2s+IGhhcyBzb21lIGFkZGVkIHNlbWFu dGljcyBhYm91dCBsb2NraW5nIGNhbmRpZGF0ZSBkYXRhIHN0b3JlcyB0aGF0IGFyZSB1bmRlc2ly YWJsZSBoZXJlLiBDdXJyZW50IHhzZCBkb2Vzbid0IGFsbG93IHRoaXMuIFNlbWFudGljcyBhcmUg ZGlmZmVyZW50IGVub3VnaCB0byB3YXJyYW50IG5ldyBvcGVyYXRpb24gbmFtZS4gDQotIFNob3Vs ZCB1c2UgbmV3IFlBTkcgImZlYXR1cmUiIGNvbnN0cnVjdCB0byBkZWNsYXJlIHdoZXRoZXIgZnVs bCBYUGF0aCBjYW4gYmUgdXNlZCwgYW5kIHdoaWNoIGRhdGFzdG9yZXMoPykNCkJhbGF6cyBwcm9w b3NlcyB0byByZWplY3Q6IGF2b2lkIGhhdmluZyBtYW55IHN1Yi1mZWF0dXJlcywgZXhpc3Rpbmcg IlhQYXRoIiBmZWF0dXJlIHNob3VsZCBjb3ZlciB0aGlzLg0KDQpTaGFyb24gQ2hpc2hvbG0gYWdy ZWVzIHdpdGggQmFsYXN6JyBwcm9wb3NlZCByZXNvbHV0aW9ucy4NCkRhdmlkIEhhcnJpbmd0b24g dGhpbmtzIGhhdmluZyB0aGUgJ2lldGYtJyBpbiBmcm9udCBtaWdodCBiZSBhIGdvb2QgdGhpbmcg YmVjYXVzZSBvdGhlciBwZW9wbGUgbWlnaHQgZm9yZ2V0IHRvIHB1dCB0aGVpciBlbnRlcnByaXNl IG5hbWUgaW4gZnJvbnQuDQoNCkJhbGFzeiBkb2Vzbid0IGhhdmUgYSBzdHJvbmcgb3Bpbmlvbi4g IFdlIGp1c3QgbmVlZCBhIGRlY2lzaW9uLg0KDQpCZXJ0IGFyZ3VlcyBvbiBEYXZlIEguJ3Mgc2lk ZSBpbiBvcmRlciB0byBhdm9pZCBwcm9ibGVtcy4NClNoYXJvbjogZG9uJ3QgdGhlIFlBTkcgbW9k dWxlIGhhdmUgJ2lldGYnIGluIHRoZWlyIG5hbWVzIGJ5IHZpcnR1ZSBvZiB0aGVpciBVUkxzPyAN CkJhbGFzejogT25seSB0aGUgbmFtZXNwYWNlIG5hbWVzLCBub3QgdGhlIG1vZHVsZSBuYW1lcy4N Ckp1ZXJnZW4gYWxzbyBwcmVmZXJzIHRvIGhhdmUgdGhlICdpZXRmLScgcHJlZml4Lg0KRGFuIFJv bWFzY2FudSBhc2tzIHdoeSB3ZSBoYXZlIHRoaXMgZGlzY3Vzc2lvbiBoZXJlLg0KQmFsYXN6OiBU aGlzIGlzIGJlY2F1c2UgdGhpcyBpcyBvbmUgb2YgdGhlIGZpcnN0IGRvY3VtZW50cyB1c2luZyBZ QU5HLg0KRGFuIFJvbWFzY2FudSBzdWdnZXN0cyB0aGF0IHRoZSBZQU5HIGRvY3VtZW50cyBzaG91 bGQgYmUgZW5oYW5jZWQgdG8gY29udGFpbiBzb21lIGd1aWRhbmNlIG9uIHRoaXMuDQpBbmR5IEJp ZXJtYW4gc3VnZ2VzdHMgdG8gdXNlIHRoZSBXRyBuYW1lIHJhdGhlciB0aGFuICdpZXRmLScuICBO byBzdXBwb3J0IGZvciB0aGlzIGluIHRoZSByb29tLg0KU2hvdyBvZiBoYW5kcyBhYm91dCBtb2R1 bGUgbmFtZSBwcmVmaXggaXNzdWU6IDE4IGluIGZhdm9yIG9mIHRoZSBpZXRmLSBwcmVmaXgsIDMg Zm9yIHBsYWluICdwYXJ0aWFsLWxvY2tpbmcnLg0KDQpCZXJ0IHN1Z2dlc3RzIGEgc2hvdyBvZiBo YW5kcyBvbiB3aG8gZmluZHMgdGhlIHJlbWFpbmluZyBwcm9wb3NlZCByZXNvbHV0aW9ucyBhY2Nl cHRhYmxlLg0KVXBvbiBEYXZlIEguJ3MgcmVxdWVzdCwgQmFsYXN6IGZpcnN0IGV4cGxhaW5zIHRo ZSBwcm9wb3NlZCAobm9uLSljaGFuZ2VzIGluIG1vcmUgZGV0YWlsLg0KRGlzY3Vzc2lvbiBiZXR3 ZWVuIERhdmUgSC4sIEJhbGFzeiwgYW5kIE1hcnRpbiBCam9lcmtsdW5kIGFib3V0IHRoZSBzY29w ZSBvZiB0aGUgKGZ1bGwpIFhQYXRoIGNhcGFiaWxpdHkuDQpQaGlsLCBjaGFubmVsZWQgYnkgQW5k eSwgY2hhbm5lbGVkIGJ5IERhdmlkIFBhcnRhaW46IHRoZSBjdXJyZW50IFhQYXRoIGNhcGFiaWxp dHkgb25seSByZWZlcnMgdG8gPGmVydDogU2hvdWxkIHdlIGRlZmVyIGdlbmVyYWxpemF0aW9uIHRvIG5ldG1vZCB3b3JrPw0K TWFyazogeWVzLiAgQWxsIHNpbWlsYXIgZGF0YSB0eXBlIGRlZmluaXRpb24gYXR0ZW1wdHMgd291 bGQgcnVuIGludG8gdGhlIHNhbWUgcHJvYmxlbS4NCkJlcnQ6IFdlIG1heSBuZWVkIHRvIGFkZCBj b21tZW50IHRvIGFsbCBkYXRhIG1vZGVscyB0aGF0IHRoZXkgbWlnaHQgY2hhbmdlLg0KQmVydDog QW55IG9iamVjdGlvbnM/IENvbnNlbnN1cyBkZWNsYXJlZC4NCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpQ YXJ0aWFsIExvY2sgUlBDIGZvciBORVRDT05GIChCYWxhenMgTGVuZ3llbCkNCmRyYWZ0LWlldGYt bmV0Y29uZi1wYXJ0aWFsLWxvY2stMDQNCg0KU2xpZGVzOiBodHRwOi8vd3d3My5pZXRmLm9yZy9w cm9jZWVkaW5ncy8wOG5vdi9zbGlkZXMvbmV0Y29uZi0xLnBwdA0KDQpHb3QgZ29vZCBjb21tZW50 cyBmcm9tIFdHTEMsIG1vc3RseSBjbGFyaWZpY2F0aW9ucywgaW1wcm92ZW1lbnRzLg0KDQoNClN1 YnN0YW50aWFsIGNoYW5nZXM6DQotIGFkZGVkIGxpc3Qgb2YgbG9ja2VkLW5vZGVzIHRvIHRoZSBv dXRwdXQgb2YgcGFydGlhbC1sb2NrIHRvIGNsYXJpZnkgd2hhdCBpcyBhY3R1YWxseSBsb2NrZWQg YXMgYSByZXN1bHQgb2Ygc29tZXdoYXQgY29tcGxleCBYUGF0aCBzZWxlY3Rpb24NCi0gYWxsb3dl ZCBhdG9taWMgbG9ja2luZyAoaW4gb25lIG9wZXJhdGlvbikgb2YgZGF0YXN0b3JlIHBhcnRzIGlu IG11bHRpcGxlIGRhdGFzdG9yZXMNCg0KTW9yZSByZWNlbnQgY29tbWVudHMgZnJvbSBQaGlsIFNo YWZlciwgd2hvIGNhbm5vdCBiZSBpbiB0aGUgc2Vzc2lvbiB0b2RheS4gRWRpdG9yaWFsIGNvbW1l bnRzIGFjY2VwdGVkLCBvdGhlcnMgbmVlZCB0byBiZSBkaXNjdXNzZWQgd2l0aCBoaW0uDQoNCkhv dyBzaG91bGQgdGhlIFlBTkcgbW9kdWxlcyBiZSBuYW1lZCBpbiB0aGUgZnV0dXJlPyBTaG91bGQg dGhleSBoYXZlIGEgcHJlZml4IGlldGYtPw0KQmFsYXN6IHRoaW5rcyB0aGlzIHNob3VsZCBiZSBq dXN0ICdwYXJ0aWFsLWxvY2tpbmcnOyBldmVyeWJvZHkgZWxzZSBjYW4gdXNlIHByZWZpeCwgaWV0 ZiBzaG91bGRuJ3QgbmVlZCB0by4NCg0KUHJvcG9zYWw6IEV4dGVuZCBnbG9iYWwgPGxvY2s+IG9w ZXJhdGlvbiByYXRoZXIgdGhhbiBpbnZlbnRpbmcgbmV3IG9wZXJhdGlvbg0KQmFsYXpzIHByb3Bv c2VzIHRvIHJlamVjdCB0aGlzOg0KLSBnbG9iYWwgPGxvY2s+IGhhcyBzb21lIGFkZGVkIHNlbWFu dGljcyBhYm91dCBsb2NraW5nIGNhbmRpZGF0ZSBkYXRhIHN0b3JlcyB0aGF0IGFyZSB1bmRlc2ly YWJsZSBoZXJlLiBDdXJyZW50IHhzZCBkb2Vzbid0IGFsbG93IHRoaXMuIFNlbWFudGljcyBhcmUg ZGlmZmVyZW50IGVub3VnaCB0byB3YXJyYW50IG5ldyBvcGVyYXRpb24gbmFtZS4gDQotIFNob3Vs ZCB1c2UgbmV3IFlBTkcgImZlYXR1cmUiIGNvbnN0cnVjdCB0byBkZWNsYXJlIHdoZXRoZXIgZnVs bCBYUGF0aCBjYW4gYmUgdXNlZCwgYW5kIHdoaWNoIGRhdGFzdG9yZXMoPykNCkJhbGF6cyBwcm9w b3NlcyB0byByZWplY3Q6IGF2b2lkIGhhdmluZyBtYW55IHN1Yi1mZWF0dXJlcywgZXhpc3Rpbmcg IlhQYXRoIiBmZWF0dXJlIHNob3VsZCBjb3ZlciB0aGlzLg0KDQpTaGFyb24gQ2hpc2hvbG0gYWdy ZWVzIHdpdGggQmFsYXN6JyBwcm9wb3NlZCByZXNvbHV0aW9ucy4NCkRhdmlkIEhhcnJpbmd0b24g dGhpbmtzIGhhdmluZyB0aGUgJ2lldGYtJyBpbiBmcm9udCBtaWdodCBiZSBhIGdvb2QgdGhpbmcg YmVjYXVzZSBvdGhlciBwZW9wbGUgbWlnaHQgZm9yZ2V0IHRvIHB1dCB0aGVpciBlbnRlcnByaXNl IG5hbWUgaW4gZnJvbnQuDQoNCkJhbGFzeiBkb2Vzbid0IGhhdmUgYSBzdHJvbmcgb3Bpbmlvbi4g IFdlIGp1c3QgbmVlZCBhIGRlY2lzaW9uLg0KDQpCZXJ0IGFyZ3VlcyBvbiBEYXZlIEguJ3Mgc2lk ZSBpbiBvcmRlciB0byBhdm9pZCBwcm9ibGVtcy4NClNoYXJvbjogZG9uJ3QgdGhlIFlBTkcgbW9k dWxlIGhhdmUgJ2lldGYnIGluIHRoZWlyIG5hbWVzIGJ5IHZpcnR1ZSBvZiB0aGVpciBVUkxzPyAN CkJhbGFzejogT25seSB0aGUgbmFtZXNwYWNlIG5hbWVzLCBub3QgdGhlIG1vZHVsZSBuYW1lcy4N Ckp1ZXJnZW4gYWxzbyBwcmVmZXJzIHRvIGhhdmUgdGhlICdpZXRmLScgcHJlZml4Lg0KRGFuIFJv bWFzY2FudSBhc2tzIHdoeSB3ZSBoYXZlIHRoaXMgZGlzY3Vzc2lvbiBoZXJlLg0KQmFsYXN6OiBU aGlzIGlzIGJlY2F1c2UgdGhpcyBpcyBvbmUgb2YgdGhlIGZpcnN0IGRvY3VtZW50cyB1c2luZyBZ QU5HLg0KRGFuIFJvbWFzY2FudSBzdWdnZXN0cyB0aGF0IHRoZSBZQU5HIGRvY3VtZW50cyBzaG91 bGQgYmUgZW5oYW5jZWQgdG8gY29udGFpbiBzb21lIGd1aWRhbmNlIG9uIHRoaXMuDQpBbmR5IEJp ZXJtYW4gc3VnZ2VzdHMgdG8gdXNlIHRoZSBXRyBuYW1lIHJhdGhlciB0aGFuICdpZXRmLScuICBO byBzdXBwb3J0IGZvciB0aGlzIGluIHRoZSByb29tLg0KU2hvdyBvZiBoYW5kcyBhYm91dCBtb2R1 bGUgbmFtZSBwcmVmaXggaXNzdWU6IDE4IGluIGZhdm9yIG9mIHRoZSBpZXRmLSBwcmVmaXgsIDMg Zm9yIHBsYWluICdwYXJ0aWFsLWxvY2tpbmcnLg0KDQpCZXJ0IHN1Z2dlc3RzIGEgc2hvdyBvZiBo YW5kcyBvbiB3aG8gZmluZHMgdGhlIHJlbWFpbmluZyBwcm9wb3NlZCByZXNvbHV0aW9ucyBhY2Nl cHRhYmxlLg0KVXBvbiBEYXZlIEguJ3MgcmVxdWVzdCwgQmFsYXN6IGZpcnN0IGV4cGxhaW5zIHRo ZSBwcm9wb3NlZCAobm9uLSljaGFuZ2VzIGluIG1vcmUgZGV0YWlsLg0KRGlzY3Vzc2lvbiBiZXR3 ZWVuIERhdmUgSC4sIEJhbGFzeiwgYW5kIE1hcnRpbiBCam9lcmtsdW5kIGFib3V0IHRoZSBzY29w ZSBvZiB0aGUgKGZ1bGwpIFhQYXRoIGNhcGFiaWxpdHkuDQpQaGlsLCBjaGFubmVsZWQgYnkgQW5k eSwgY2hhbm5lbGVkIGJ5IERhdmlkIFBhcnRhaW46IHRoZSBjdXJyZW50IFhQYXRoIGNhcGFiaWxp dHkgb25seSByZWZlcnMgdldD4gYW5kIDxnZXQtY29uZmlnPiwgbm90aGluZyBlbHNlIQ0K QmVydDogVGhpcyBsb29rcyBsaWtlIGl0IG5lZWRzIG1vcmUgZGlzY3Vzc2lvbi4NCg0KQmFsYXN6 IGNvbnRpbnVlcyB3aXRoIGFub3RoZXIgaXNzdWU6IHRoZSBYTUwgZW5jb2Rpbmcgb2YgdGhlIDxw YXJ0aWFsLWxvY2s+IHJlcXVlc3QuICANCkN1cnJlbnQgcHJvcG9zYWw6IDx0YXJnZXQ+IGNhbiBj b250YWluIG11bHRpcGxlIGVsZW1lbnRzLiAgVGhlIGFsdGVybmF0aXZlIHN1Z2dlc3RlZCBieSBQ aGlsOiA8dGFyZ2V0PiBjb250YWlucyBhIHNpbmdsZSBlbGVtZW50LCBvciBhIGNvbmZpZ3VyYXRp b24gc3RvcmUgbmFtZSBhcyBhIHN0cmluZyAoY291bGQgYWxzbyBiZSBhbiBlbnVtZXJhdGlvbiBv ZiBtdWx0aXBsZSB0YXJnZXRzPyksIGFuZCB0aGVyZSBjYW4gYmUgbXVsdGlwbGUgPHRhcmdldD4g ZWxlbWVudHMuDQoNClNoYXJvbiBhbmQgRGF2ZSBILiBleHByZXNzIHRoZWlyIHByZWZlcmVuY2Ug Zm9yIHRoZSBmaXJzdCB2YXJpYW50Lg0KQmFsYXN6IGhhcyBhbHJlYWR5IHNlbnQgYSBzZXZlbi1w YWdlIHJlc3BvbnNlIHRvIFBoaWwncyBzdWdnZXN0aW9ucyBvbiB0aGUgbWFpbGluZyBsaXN0IHRv ZGF5Lg0KDQpCZXJ0OiBwbGVhc2UganVtcCBpbiBvbiB0aGUgbWFpbGluZyBsaXN0IGlmIHlvdSBo YXZlIGlzc3VlcyB3aXRoIGFueSBvZiB0aGVzZSBwcm9wb3NhbHMhIHdvdWxkIGxpa2UgdG8gZ2V0 IHRoaXMgY29uY2x1ZGVkIHNvb24sIHNpbmNlIHdlDQphbHJlYWR5IGhhZCBhIFdvcmtpbmcgR3Jv dXAgTGFzdCBDYWxsLg0KDQpBbmR5IGNsYXJpZmllcyB0aGF0IGluIHRlcm1zIG9mIFlBTkcsIA0K JygxKSBpcyBhbiBOUCBjb250YWluZXIgb2YgZW1wdHkgYW5kICgyKSBpcyBhIGxlYWYtbGlzdCBv ZiBlbXB0eTsgZG9uJ3QgY2FyZSBidXQgKDIpIGlzIG1vcmUgY29ycmVjdCBZQU5HJw0KDQpCYWxh c3ogc2F5cyB0aGF0IHRoZSBjdXJyZW50IHByb3Bvc2FsICgxKSBjYW4gYWxzbyBiZSBzcGVjaWZp ZWQgaW4gWUFORyAtIGl0IGFscmVhZHkgaXMgc3BlY2lmaWVkIGluIHRoaXMgd2F5Lg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNCk5FVENPTkYgb3ZlciBUTFMNCg0KRG9jdW1lbnQgaXMgaW4gQUQgcmV2aWV3 IGJ5IERhbi4gTWVobWV0IHdpbGwgYmUgc2hlcGhlcmRpbmcgdGhpcy4NClNlY3VyaXR5IEFEcyBn YXZlIHRoZWlyIGZlZWRiYWNrIChQYXNpIEVyb25lbikuIE11bHRpcGxlIHNlY2RpciBtZW1iZXJz IGFsc28gcmV2aWV3ZWQgdGhlIGRyYWZ0Lg0KQUQgRGFuIFJvbWFzY2FudSB1bmRlcnN0YW5kcyB0 aGF0IGl0IGlzbid0IG5lY2Vzc2FyeSB0byBnZXQgYWRkaXRpb25hbCBzZWN1cml0eSBleHBlcnQg cmV2aWV3cy4gIFdlIHNob3VsZCBzZWUgdGhpcyBnb2luZyB0byBJRVRGIGxhc3QgY2FsbCBzaG9y dGx5Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCklzc3VlcyBmb3IgNDc0MWJpcy1kcmFmdCAtIE1hcnRp biBCam9lcmtsdW5kIA0KDQpTbGlkZXM6IGh0dHA6Ly93d3czLmlldGYub3JnL3Byb2NlZWRpbmdz LzA4bm92L3NsaWRlcy9uZXRjb25mLTMucGRmDQoNCk1hcnRpbiBhbmQgSnVlcmdlbiBTY2hvZW53 YWVsZGVyIGhhdmUga2luZGx5IHZvbHVudGVlcmVkIHRvIHdvcmsgb24gdGhpcy4NCg0KU2hvdWxk IGp1c3QgZG8gYnVnIGZpeGVzIGFuZCBjbGFyaWZpY2F0aW9ucy4gIFRoaXMgaXMgbm90IHN1cHBv c2VkIHRvIGJlIE5FVENPTkYgVjIuMC4NCg0KSXNzdWVzIGJhc2VkIG9uIGltcGxlbWVudGF0aW9u IGV4cGVyaWVuY2UsIG1haWxpbmcgbGlzdCBmZWVkYmFjaywgYW5kIGludGVyb3BlcmFiaWxpdHkg dGVzdGluZy4NCg0KTWFydGluIGFza3Mgd2hvIGltcGxlbWVudHMgaW5saW5lIGNvbmZpZ3VyYXRp b24gdmFsaWRhdGlvbi4NCkFuZHkgQmllcm1hbiAodmlhIGphYmJlcikgc2F5cyBoZSBpbXBsZW1l bnRzIGl0LCBhcyBvcGVyYXRpbmcgb24gYSBjb21wbGV0ZSBjb25maWd1cmF0aW9uLg0KDQpTaGFy b24gYXNrcyB3aHkgOnN0YXJ0dXAgYW5kIDpjYW5kaWRhdGUgc2hvdWxkIGJlIG11dHVhbGx5IGV4 Y2x1c2l2ZT8NCk1hcnRpbiB0aGlua3MgdGhleSBzaG91bGRuJ3QsIGJ1dCBzb21lIHBlb3BsZSBh cmd1ZSB0aGF0IHRoZXkgc2hvdWxkbid0IGJlIGFsbG93ZWQgdG9nZXRoZXIuDQoNCkJlcnQgcmVt aW5kcyBwZW9wbGUgdGhhdCB3ZSBkb24ndCBoYXZlIHRvIHJlc29sdmUgYWxsIHRoZXNlIGlzc3Vl cyBpbiB0aGlzIHNlc3Npb247IHRoaXMgaXMgbW9yZSB0byBnaXZlIGFuIGltcHJlc3Npb24gd2hh dCB0aGUgc2NvcGUgb2YNCnRoaXMgNDc0MWJpcyB3b3JrIGlzLg0KDQpCZXJ0OiBEbyB5b3UgaGF2 ZSBhIHRpbWVsaW5lIGZvciB0aGUgZG91bWVudD8NCk1hcnRpbjogTm8gd2UgaGF2ZSBub3QgYWRk cmVzc2VkIHRpbWVsaW5lIHlldC4gSnVzdCBjb2xsZWN0aW5nIGlzc3Vlcy4NCk1laG1ldDogRm9y IGEgY2hhcnRlciB1cGRhdGUgd2UgbmVlZCBhIHRpbWVsaW5lIGZvciB0aGUgZG9jdW1lbnQgZGV2 ZWxvcG1lbnQgdGhvdWdoLiBXZSBuZWVkIHRvIGRlZmluZSBhIHRpbWVsaW5lIG5leHQgd2Vlay4N Cg0KU2hhcm9uIHJlbWluZHMgcGVvcGxlIHRoYXQgYXQgc29tZSBwb2ludCwgdGhlIHRyYW5zcG9y dCBtYXBwaW5nIGRvY3VtZW50cyB3aWxsIGhhdmUgdG8gYmUgZWRpdGVkIHRvIHN1cHBvcnQgbm90 aWZpY2F0aW9uIHRyYW5zcG9ydC4NCg0KRGF2ZSBIYXJyaW5ndG9uIGFza3MgaG93IGl0IHdvdWxk IGJlIHBvc3NpYmxlIHRvIGdldCBhIHN0YXJ0dXAgY29uZmlndXJhdGlvbiB0aGF0IGlzIGRpZmZl cmVudCBmcm9tIGFueSBjdXJyZW50IGNvbmZpZ3VyYXRpb24uDQpNYXJ0aW4gc2F5cyB0aGF0IHRo aXMgaXMgY3VycmVudGx5IG5vdCBwb3NzaWJsZTsgaWYgZGVzaXJlZCwgdGhlIHRleHQgd291bGQg aGF2ZSB0byBiZSBjaGFuZ2VkLg0KDQpEaXNjdXNzadG8gPGdldD4gYW5kIDxnZXQtY29uZmlnPiwgbm90aGluZyBlbHNlIQ0K QmVydDogVGhpcyBsb29rcyBsaWtlIGl0IG5lZWRzIG1vcmUgZGlzY3Vzc2lvbi4NCg0KQmFsYXN6 IGNvbnRpbnVlcyB3aXRoIGFub3RoZXIgaXNzdWU6IHRoZSBYTUwgZW5jb2Rpbmcgb2YgdGhlIDxw YXJ0aWFsLWxvY2s+IHJlcXVlc3QuICANCkN1cnJlbnQgcHJvcG9zYWw6IDx0YXJnZXQ+IGNhbiBj b250YWluIG11bHRpcGxlIGVsZW1lbnRzLiAgVGhlIGFsdGVybmF0aXZlIHN1Z2dlc3RlZCBieSBQ aGlsOiA8dGFyZ2V0PiBjb250YWlucyBhIHNpbmdsZSBlbGVtZW50LCBvciBhIGNvbmZpZ3VyYXRp b24gc3RvcmUgbmFtZSBhcyBhIHN0cmluZyAoY291bGQgYWxzbyBiZSBhbiBlbnVtZXJhdGlvbiBv ZiBtdWx0aXBsZSB0YXJnZXRzPyksIGFuZCB0aGVyZSBjYW4gYmUgbXVsdGlwbGUgPHRhcmdldD4g ZWxlbWVudHMuDQoNClNoYXJvbiBhbmQgRGF2ZSBILiBleHByZXNzIHRoZWlyIHByZWZlcmVuY2Ug Zm9yIHRoZSBmaXJzdCB2YXJpYW50Lg0KQmFsYXN6IGhhcyBhbHJlYWR5IHNlbnQgYSBzZXZlbi1w YWdlIHJlc3BvbnNlIHRvIFBoaWwncyBzdWdnZXN0aW9ucyBvbiB0aGUgbWFpbGluZyBsaXN0IHRv ZGF5Lg0KDQpCZXJ0OiBwbGVhc2UganVtcCBpbiBvbiB0aGUgbWFpbGluZyBsaXN0IGlmIHlvdSBo YXZlIGlzc3VlcyB3aXRoIGFueSBvZiB0aGVzZSBwcm9wb3NhbHMhIHdvdWxkIGxpa2UgdG8gZ2V0 IHRoaXMgY29uY2x1ZGVkIHNvb24sIHNpbmNlIHdlDQphbHJlYWR5IGhhZCBhIFdvcmtpbmcgR3Jv dXAgTGFzdCBDYWxsLg0KDQpBbmR5IGNsYXJpZmllcyB0aGF0IGluIHRlcm1zIG9mIFlBTkcsIA0K JygxKSBpcyBhbiBOUCBjb250YWluZXIgb2YgZW1wdHkgYW5kICgyKSBpcyBhIGxlYWYtbGlzdCBv ZiBlbXB0eTsgZG9uJ3QgY2FyZSBidXQgKDIpIGlzIG1vcmUgY29ycmVjdCBZQU5HJw0KDQpCYWxh c3ogc2F5cyB0aGF0IHRoZSBjdXJyZW50IHByb3Bvc2FsICgxKSBjYW4gYWxzbyBiZSBzcGVjaWZp ZWQgaW4gWUFORyAtIGl0IGFscmVhZHkgaXMgc3BlY2lmaWVkIGluIHRoaXMgd2F5Lg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNCk5FVENPTkYgb3ZlciBUTFMNCg0KRG9jdW1lbnQgaXMgaW4gQUQgcmV2aWV3 IGJ5IERhbi4gTWVobWV0IHdpbGwgYmUgc2hlcGhlcmRpbmcgdGhpcy4NClNlY3VyaXR5IEFEcyBn YXZlIHRoZWlyIGZlZWRiYWNrIChQYXNpIEVyb25lbikuIE11bHRpcGxlIHNlY2RpciBtZW1iZXJz IGFsc28gcmV2aWV3ZWQgdGhlIGRyYWZ0Lg0KQUQgRGFuIFJvbWFzY2FudSB1bmRlcnN0YW5kcyB0 aGF0IGl0IGlzbid0IG5lY2Vzc2FyeSB0byBnZXQgYWRkaXRpb25hbCBzZWN1cml0eSBleHBlcnQg cmV2aWV3cy4gIFdlIHNob3VsZCBzZWUgdGhpcyBnb2luZyB0byBJRVRGIGxhc3QgY2FsbCBzaG9y dGx5Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCklzc3VlcyBmb3IgNDc0MWJpcy1kcmFmdCAtIE1hcnRp biBCam9lcmtsdW5kIA0KDQpTbGlkZXM6IGh0dHA6Ly93d3czLmlldGYub3JnL3Byb2NlZWRpbmdz LzA4bm92L3NsaWRlcy9uZXRjb25mLTMucGRmDQoNCk1hcnRpbiBhbmQgSnVlcmdlbiBTY2hvZW53 YWVsZGVyIGhhdmUga2luZGx5IHZvbHVudGVlcmVkIHRvIHdvcmsgb24gdGhpcy4NCg0KU2hvdWxk IGp1c3QgZG8gYnVnIGZpeGVzIGFuZCBjbGFyaWZpY2F0aW9ucy4gIFRoaXMgaXMgbm90IHN1cHBv c2VkIHRvIGJlIE5FVENPTkYgVjIuMC4NCg0KSXNzdWVzIGJhc2VkIG9uIGltcGxlbWVudGF0aW9u IGV4cGVyaWVuY2UsIG1haWxpbmcgbGlzdCBmZWVkYmFjaywgYW5kIGludGVyb3BlcmFiaWxpdHkg dGVzdGluZy4NCg0KTWFydGluIGFza3Mgd2hvIGltcGxlbWVudHMgaW5saW5lIGNvbmZpZ3VyYXRp b24gdmFsaWRhdGlvbi4NCkFuZHkgQmllcm1hbiAodmlhIGphYmJlcikgc2F5cyBoZSBpbXBsZW1l bnRzIGl0LCBhcyBvcGVyYXRpbmcgb24gYSBjb21wbGV0ZSBjb25maWd1cmF0aW9uLg0KDQpTaGFy b24gYXNrcyB3aHkgOnN0YXJ0dXAgYW5kIDpjYW5kaWRhdGUgc2hvdWxkIGJlIG11dHVhbGx5IGV4 Y2x1c2l2ZT8NCk1hcnRpbiB0aGlua3MgdGhleSBzaG91bGRuJ3QsIGJ1dCBzb21lIHBlb3BsZSBh cmd1ZSB0aGF0IHRoZXkgc2hvdWxkbid0IGJlIGFsbG93ZWQgdG9nZXRoZXIuDQoNCkJlcnQgcmVt aW5kcyBwZW9wbGUgdGhhdCB3ZSBkb24ndCBoYXZlIHRvIHJlc29sdmUgYWxsIHRoZXNlIGlzc3Vl cyBpbiB0aGlzIHNlc3Npb247IHRoaXMgaXMgbW9yZSB0byBnaXZlIGFuIGltcHJlc3Npb24gd2hh dCB0aGUgc2NvcGUgb2YNCnRoaXMgNDc0MWJpcyB3b3JrIGlzLg0KDQpCZXJ0OiBEbyB5b3UgaGF2 ZSBhIHRpbWVsaW5lIGZvciB0aGUgZG91bWVudD8NCk1hcnRpbjogTm8gd2UgaGF2ZSBub3QgYWRk cmVzc2VkIHRpbWVsaW5lIHlldC4gSnVzdCBjb2xsZWN0aW5nIGlzc3Vlcy4NCk1laG1ldDogRm9y IGEgY2hhcnRlciB1cGRhdGUgd2UgbmVlZCBhIHRpbWVsaW5lIGZvciB0aGUgZG9jdW1lbnQgZGV2 ZWxvcG1lbnQgdGhvdWdoLiBXZSBuZWVkIHRvIGRlZmluZSBhIHRpbWVsaW5lIG5leHQgd2Vlay4N Cg0KU2hhcm9uIHJlbWluZHMgcGVvcGxlIHRoYXQgYXQgc29tZSBwb2ludCwgdGhlIHRyYW5zcG9y dCBtYXBwaW5nIGRvY3VtZW50cyB3aWxsIGhhdmUgdG8gYmUgZWRpdGVkIHRvIHN1cHBvcnQgbm90 aWZpY2F0aW9uIHRyYW5zcG9ydC4NCg0KRGF2ZSBIYXJyaW5ndG9uIGFza3MgaG93IGl0IHdvdWxk IGJlIHBvc3NpYmxlIHRvIGdldCBhIHN0YXJ0dXAgY29uZmlndXJhdGlvbiB0aGF0IGlzIGRpZmZl cmVudCBmcm9tIGFueSBjdXJyZW50IGNvbmZpZ3VyYXRpb24uDQpNYXJ0aW4gc2F5cyB0aGF0IHRo aXMgaXMgY3VycmVudGx5IG5vdCBwb3NzaWJsZTsgaWYgZGVzaXJlZCwgdGhlIHRleHQgd291bGQg aGF2ZSB0byBiZSBjaGFuZ2VkLg0KDQpEaXNW9uIGFib3V0IHRoZSBpc3N1ZSB0aGF0IHRo ZSB4c2QgZGlzYWxsb3dzIHNvbWUgZXh0ZW5zaW9ucyB0aHJvdWdoIG9wdGlvbmFsIGNhcGFiaWxp dGllcy4NCg0KU2hhcm9uIHRoaW5rcyBzdWNoIGV4dGVuc2lvbnMgd291bGQgdHlwaWNhbGx5IG5v dCBiZSBhIHByb2JsZW0gaW4gdGhhdCB0aGV5IG9ubHkgYWRkIGFkZGl0aW9uYWwgcmVxdWVzdCBh dHRyaWJ1dGVzLCBhbmQgY2Fubm90IGluIHRoZSBzZXJ2ZXINCnJldHVybmluZyBjb250ZW50IHRo YXQgY291bGQgYmUgdW5leHBlY3RlZCBieSB0aGUgY2xpZW50Lg0KDQpBbmR5OiB0aGUgWE1MIHBy ZWFtYmxlIGlzIG5vdCBvcHRpb25hbC4gIGRvbid0IGJyZWFrIHJmYzQ3NDEtY29tcGxpYW50IGNs aWVudHMgdGhhdCBleHBlY3QgaXQuDQoNCj8/PyAoc29ycnksIGRpZG4ndCBnZXQgdGhlIG5hbWUp IGFsc28gcmVjb21tZW5kcyB0byBsZWF2ZSB0aGUgPHhtbD4gaGVhZGVyIG1hbmRhdG9yeSwgYmVj YXVzZSBpdCBhbHNvIHNwZWNpZmllZCB0aGUgZW5jb2RpbmcuICBNaXNzaW5nIGVuY29kaW5nIGlu Zm9ybWF0aW9uIGlzIGEgZnJlcXVlbnQgc291cmNlIG9mIGludGVyb3BlcmFiaWxpdHkgcHJvYmxl bXMuDQoNCkRhbiBSb21hc2NhbnU6IElzIHlvdXIgbGlzdCBvZiBpc3N1ZXMgc29tZWhvdyBzb3J0 ZWQ/DQpNYXJ0aW46IE5vLCBqdXN0IGNvbXBpbGVkIGEgbGlzdCBvZiBpc3N1ZXMuICBOZWVkIGZl ZWRiYWNrLg0KDQpEYW4gUm9tYXNjYW51OiBZb3Ugc2FpZCB0aGlzIGlzIG5vdCBORVRDT05GIDIu MCAobW9yZSBsaWtlIE5FVENPTkYgMS4xKSwgc28gb25seSBidWcgZml4ZXMgYW5kIGNsYXJpZmlj YXRpb25zLiAgQnV0IGR1cmluZyB0aGUgcHJlc2VudGF0aW9uIEkgaGFkIHRoZSBmZWVsaW5nIHRo YXQgaXQgbWF5IG5vdCBiZSBwb3NzaWJsZSB0byBlbnN1cmUgYmFja3dhcmRzIGNvbXBhdGliaWxp dHkgaW4gYWxsIGNhc2VzLCB2aXouIHRoZSBoYW5kbGluZyBvZiB0aGUgc3RhcnR1cCBjb25maWd1 cmF0aW9uKD8pLg0KTWFydGluOiBUaGlzIGlzIHNvbWV0aGluZyB0byBoYXZlIHRvIGxvb2sgaW50 bzogRm9yIGVhY2ggY2hhbmdlLCBob3cgd2lsbCBpdCBhZmZlY3QgY2xpZW50cywgaXMgaXQgbmVj ZXNzYXJ5IHRvIGludHJvZHVjZSBuZXcgY2FwYWJpbGl0aWVzPw0KSnVlcmdlbiB2aWEgamFiYmVy OiBJbXBsZW1lbnRhdGlvbnMgY3VycmVudGx5IGJlaGF2ZSBkaWZmZXJlbnRseSwgYW5kIHRoZSBn b2FsIGlzIHRvIGRlZmluZSB3aGF0IHRoZSBkZXNpcmVkIGJlaGF2aW9yIGlzLg0KRGF2ZSBIYXJy aW5ndG9uOiBIYXZlIHlvdSBjb25zaWRlcmVkIHRha2luZyB0aGlzIHRvIGRyYWZ0IHN0YW5kYXJk PyBUaGF0IHdvdWxkIGFjdHVhbGx5IGFsbG93IHlvdSB0byBubyBsb25nZXIgYmUgY29tcGxldGVs eSBiYWNrd2FyZCBjb21wYXRpYmxlLg0KTWFydGluOiBUaGF0IHdvdWxkIGRlcGVuZCBvbiB3aGF0 IHRoZSB3b3JraW5nIGdyb3VwIHdhbnRzLg0KRGF2ZSBIYXJyaW5ndG9uOiBIYXMgYW55dGhpbmcg YmVlbiBwdWJsaXNoZWQgb24gdGhlIGludGVyb3BlcmFiaWxpdHkgdGVzdGluZz8NCk1hcnRpbjog SnVlcmdlbiBpcyBwcmVwYXJpbmcgc29tZXRoaW5nLg0KDQpCZXJ0OiBUaGFua3MgTWFydGluIGZv ciBjb21waWxpbmcgdGhpcyBsaXN0LiAgV2UnbGwgY29tZSBiYWNrIHRvIHRoaXMgaW4gdGhlIGNo YXJ0ZXIgZGlzY3Vzc2lvbiBsYXRlciBvbi4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQond2l0aC1kZWZh dWx0cycgY2FwYWJpbGl0eSBmb3IgTkVUQ09ORiAtIEJhbGFzeiBMZW5neWVsLCB3b3JrIHdpdGgg QW5keSBCaWVybWFuDQoNClNsaWRlczogaHR0cDovL3d3dzMuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv MDhub3Yvc2xpZGVzL25ldGNvbmYtNC5wcHQNCg0KTW90aXZhdGVkIG1vc3RseSBieSBuZXRtb2Qg ZGlzY3Vzc2lvbnMuDQoNClF1ZXN0aW9uczoNCi0gSXMgdGhpcyBpbXBvcnRhbnQ/DQotIFNob3Vs ZCB0aGlzIGJlIGEgd2cgaXRlbT8NCi0gQ2FuIHRoaXMgYmUgc29sdmVkPw0KDQpTaGFyb24gdGhp bmtzIHRoaXMgaXMgYSByZWFsbHkgaW1wb3J0YW50IHByb2JsZW0gdG8gc29sdmUsIGhhdmUgc3Bl bnQgYSBsb3Qgb2YgdGltZSBpbiB0aGVpciBvcmdhbml6YXRpb24gdGhpbmtpbmcgYWJvdXQgdGhp cy4gIE1vc3RseSBmb2xsb3dpbmcgdGhlIENMSS4gIERlZmF1bHQgdmFsdWVzIGNvbWUgaW4gZGlm ZmVyZW50IGZvcm1zLCBub3QgYWxsIG9mIHdoaWNoIGVhc2lseSBzcGVjaWZpYWJsZSBpbiBhIGRh dGEgbW9kZWwuICBTb21ldGltZXMgZGVmYXVsdHMgZGVwZW5kIG9uIHRoZSBzcGVjaWZpYyBkZXZp Y2UsIG9yIGV2ZW4gdGhlIHNwZWNpZmljIHNvZnR3YXJlIHJlbGVhc2UuDQpTaGFyb246IEl0IGlz IGltcG9ydGFudCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHZhbHVlcyBzZXQgZXhwbGljaXRseSB0 byB0aGUgc2FtZSBhcyB0aGUgZGVmYXVsdCwgYW5kIHZhbHVlcyBsZWZ0IGF0IHRoZSBkZWZhdWx0 Lg0KQmFsYXN6IGFncmVlcywgYnV0IG5vdGVzIHRoYXQgc29tZSBkZXZpY2VzIGNhbm5vdCBlYXNp bHkgcmVwcmVzZW50IGl0IGluIHRoZWlyIGN1cnJlbnQgY29uZmlndXJhdGlvbiBtb2RlbC4NCkRh dmlkIFBhcnRhaW46IFllcywgdGhpcyBpcyBpbXBvcnRhbnQsIHllcywgdGhpcyBpcyB0aGUgcmln aHQgcGxhY2UgdG8gaGFuZGxlIHRoaXMuDQoNClR3byBzZXBhcmF0ZSBzaG93cyBvZiBoYW5kcyBj b25maXJtIHRoYXQgDQooMSkgdGhlcmUgaXMgd2lkZSBjb25zZW5zdXMgaW4gdGhlIHJvb20gdGhh dCB0aGlzIGlzIGFuIGltcG9ydGFudCBpc3N1ZTogYSBsb3Qgb2YgaGFuZHMgDQooMikgdGhhdCBz dWNoIHdvcmsgc2hvdWxkIGJlIGRvbmUgd2l0aGluIHRoaXMgV0c6IDIxIGhhbmRzDQoNCkJlcnQ6 IERvIHlvdSBoYXZlIGFueSBkb3VidHMgdGhhdCBpdCBjYW4gYmUgc29sdmVkPw0KQmFsYXN6OiBO bywgYW5kIEkgdGhpbmsgbXkgZHJhZnQgZ29lcyBhIGxvbmcgd2F5IHRvjdXNzaW9uIGFib3V0IHRoZSBpc3N1ZSB0aGF0IHRo ZSB4c2QgZGlzYWxsb3dzIHNvbWUgZXh0ZW5zaW9ucyB0aHJvdWdoIG9wdGlvbmFsIGNhcGFiaWxp dGllcy4NCg0KU2hhcm9uIHRoaW5rcyBzdWNoIGV4dGVuc2lvbnMgd291bGQgdHlwaWNhbGx5IG5v dCBiZSBhIHByb2JsZW0gaW4gdGhhdCB0aGV5IG9ubHkgYWRkIGFkZGl0aW9uYWwgcmVxdWVzdCBh dHRyaWJ1dGVzLCBhbmQgY2Fubm90IGluIHRoZSBzZXJ2ZXINCnJldHVybmluZyBjb250ZW50IHRo YXQgY291bGQgYmUgdW5leHBlY3RlZCBieSB0aGUgY2xpZW50Lg0KDQpBbmR5OiB0aGUgWE1MIHBy ZWFtYmxlIGlzIG5vdCBvcHRpb25hbC4gIGRvbid0IGJyZWFrIHJmYzQ3NDEtY29tcGxpYW50IGNs aWVudHMgdGhhdCBleHBlY3QgaXQuDQoNCj8/PyAoc29ycnksIGRpZG4ndCBnZXQgdGhlIG5hbWUp IGFsc28gcmVjb21tZW5kcyB0byBsZWF2ZSB0aGUgPHhtbD4gaGVhZGVyIG1hbmRhdG9yeSwgYmVj YXVzZSBpdCBhbHNvIHNwZWNpZmllZCB0aGUgZW5jb2RpbmcuICBNaXNzaW5nIGVuY29kaW5nIGlu Zm9ybWF0aW9uIGlzIGEgZnJlcXVlbnQgc291cmNlIG9mIGludGVyb3BlcmFiaWxpdHkgcHJvYmxl bXMuDQoNCkRhbiBSb21hc2NhbnU6IElzIHlvdXIgbGlzdCBvZiBpc3N1ZXMgc29tZWhvdyBzb3J0 ZWQ/DQpNYXJ0aW46IE5vLCBqdXN0IGNvbXBpbGVkIGEgbGlzdCBvZiBpc3N1ZXMuICBOZWVkIGZl ZWRiYWNrLg0KDQpEYW4gUm9tYXNjYW51OiBZb3Ugc2FpZCB0aGlzIGlzIG5vdCBORVRDT05GIDIu MCAobW9yZSBsaWtlIE5FVENPTkYgMS4xKSwgc28gb25seSBidWcgZml4ZXMgYW5kIGNsYXJpZmlj YXRpb25zLiAgQnV0IGR1cmluZyB0aGUgcHJlc2VudGF0aW9uIEkgaGFkIHRoZSBmZWVsaW5nIHRo YXQgaXQgbWF5IG5vdCBiZSBwb3NzaWJsZSB0byBlbnN1cmUgYmFja3dhcmRzIGNvbXBhdGliaWxp dHkgaW4gYWxsIGNhc2VzLCB2aXouIHRoZSBoYW5kbGluZyBvZiB0aGUgc3RhcnR1cCBjb25maWd1 cmF0aW9uKD8pLg0KTWFydGluOiBUaGlzIGlzIHNvbWV0aGluZyB0byBoYXZlIHRvIGxvb2sgaW50 bzogRm9yIGVhY2ggY2hhbmdlLCBob3cgd2lsbCBpdCBhZmZlY3QgY2xpZW50cywgaXMgaXQgbmVj ZXNzYXJ5IHRvIGludHJvZHVjZSBuZXcgY2FwYWJpbGl0aWVzPw0KSnVlcmdlbiB2aWEgamFiYmVy OiBJbXBsZW1lbnRhdGlvbnMgY3VycmVudGx5IGJlaGF2ZSBkaWZmZXJlbnRseSwgYW5kIHRoZSBn b2FsIGlzIHRvIGRlZmluZSB3aGF0IHRoZSBkZXNpcmVkIGJlaGF2aW9yIGlzLg0KRGF2ZSBIYXJy aW5ndG9uOiBIYXZlIHlvdSBjb25zaWRlcmVkIHRha2luZyB0aGlzIHRvIGRyYWZ0IHN0YW5kYXJk PyBUaGF0IHdvdWxkIGFjdHVhbGx5IGFsbG93IHlvdSB0byBubyBsb25nZXIgYmUgY29tcGxldGVs eSBiYWNrd2FyZCBjb21wYXRpYmxlLg0KTWFydGluOiBUaGF0IHdvdWxkIGRlcGVuZCBvbiB3aGF0 IHRoZSB3b3JraW5nIGdyb3VwIHdhbnRzLg0KRGF2ZSBIYXJyaW5ndG9uOiBIYXMgYW55dGhpbmcg YmVlbiBwdWJsaXNoZWQgb24gdGhlIGludGVyb3BlcmFiaWxpdHkgdGVzdGluZz8NCk1hcnRpbjog SnVlcmdlbiBpcyBwcmVwYXJpbmcgc29tZXRoaW5nLg0KDQpCZXJ0OiBUaGFua3MgTWFydGluIGZv ciBjb21waWxpbmcgdGhpcyBsaXN0LiAgV2UnbGwgY29tZSBiYWNrIHRvIHRoaXMgaW4gdGhlIGNo YXJ0ZXIgZGlzY3Vzc2lvbiBsYXRlciBvbi4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQond2l0aC1kZWZh dWx0cycgY2FwYWJpbGl0eSBmb3IgTkVUQ09ORiAtIEJhbGFzeiBMZW5neWVsLCB3b3JrIHdpdGgg QW5keSBCaWVybWFuDQoNClNsaWRlczogaHR0cDovL3d3dzMuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv MDhub3Yvc2xpZGVzL25ldGNvbmYtNC5wcHQNCg0KTW90aXZhdGVkIG1vc3RseSBieSBuZXRtb2Qg ZGlzY3Vzc2lvbnMuDQoNClF1ZXN0aW9uczoNCi0gSXMgdGhpcyBpbXBvcnRhbnQ/DQotIFNob3Vs ZCB0aGlzIGJlIGEgd2cgaXRlbT8NCi0gQ2FuIHRoaXMgYmUgc29sdmVkPw0KDQpTaGFyb24gdGhp bmtzIHRoaXMgaXMgYSByZWFsbHkgaW1wb3J0YW50IHByb2JsZW0gdG8gc29sdmUsIGhhdmUgc3Bl bnQgYSBsb3Qgb2YgdGltZSBpbiB0aGVpciBvcmdhbml6YXRpb24gdGhpbmtpbmcgYWJvdXQgdGhp cy4gIE1vc3RseSBmb2xsb3dpbmcgdGhlIENMSS4gIERlZmF1bHQgdmFsdWVzIGNvbWUgaW4gZGlm ZmVyZW50IGZvcm1zLCBub3QgYWxsIG9mIHdoaWNoIGVhc2lseSBzcGVjaWZpYWJsZSBpbiBhIGRh dGEgbW9kZWwuICBTb21ldGltZXMgZGVmYXVsdHMgZGVwZW5kIG9uIHRoZSBzcGVjaWZpYyBkZXZp Y2UsIG9yIGV2ZW4gdGhlIHNwZWNpZmljIHNvZnR3YXJlIHJlbGVhc2UuDQpTaGFyb246IEl0IGlz IGltcG9ydGFudCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHZhbHVlcyBzZXQgZXhwbGljaXRseSB0 byB0aGUgc2FtZSBhcyB0aGUgZGVmYXVsdCwgYW5kIHZhbHVlcyBsZWZ0IGF0IHRoZSBkZWZhdWx0 Lg0KQmFsYXN6IGFncmVlcywgYnV0IG5vdGVzIHRoYXQgc29tZSBkZXZpY2VzIGNhbm5vdCBlYXNp bHkgcmVwcmVzZW50IGl0IGluIHRoZWlyIGN1cnJlbnQgY29uZmlndXJhdGlvbiBtb2RlbC4NCkRh dmlkIFBhcnRhaW46IFllcywgdGhpcyBpcyBpbXBvcnRhbnQsIHllcywgdGhpcyBpcyB0aGUgcmln aHQgcGxhY2UgdG8gaGFuZGxlIHRoaXMuDQoNClR3byBzZXBhcmF0ZSBzaG93cyBvZiBoYW5kcyBj b25maXJtIHRoYXQgDQooMSkgdGhlcmUgaXMgd2lkZSBjb25zZW5zdXMgaW4gdGhlIHJvb20gdGhh dCB0aGlzIGlzIGFuIGltcG9ydGFudCBpc3N1ZTogYSBsb3Qgb2YgaGFuZHMgDQooMikgdGhhdCBz dWNoIHdvcmsgc2hvdWxkIGJlIGRvbmUgd2l0aGluIHRoaXMgV0c6IDIxIGhhbmRzDQoNCkJlcnQ6 IERvIHlvdSBoYXZlIGFueSBkb3VidHMgdGhhdCBpdCBjYW4gYmUgc29sdmVkPw0KQmFsYXN6OiBO bywgYW5kIEkgdGhpbmsgbXkgZHJhZnQgZ29lcyBhIGxvbmcgd2IHNvbHZpbmcgaXQuDQoN CkxhZGE6IFNwZWNpZnksIGNhbiBpdCBiZSBzb2x2ZWQgaW4gYSB3YXkgdGhhdCBzYXRpc2ZpZXMg ZXZlcnlib2R5Pw0KDQpCZXJ0OiBJdCBzaG91bGQgYmUgcG9zc2libGUgdG8gYWNoaWV2ZSByb3Vn aCBjb25zZW5zdXMgLSB0aGVyZSBjYW4gc3RpbGwgYmUgbm9uLWludGVyb3BlcmFibGUgaW1wbGVt ZW50YXRpb25zLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk5FVENPTkYgTm90aWZpY2F0aW9uIENvbnRl bnQgLSBCZXJ0IFdpam5lbg0KDQpTbGlkZXM6IGh0dHA6Ly93d3czLmlldGYub3JnL3Byb2NlZWRp bmdzLzA4bm92L3NsaWRlcy9uZXRjb25mLTUucHB0DQoNCkJlcnQ6IFRoZSBmZWVsaW5nIHRoZSBX RyBjaGFpcnMgZ290IGZyb20gbGFzdCBpZXRmIG1lZXRpbmc6IA0KV2UgZG8gbm90IHdhbnQgdG8g ZGVmaW5lIGV4dGVuc2l2ZSBub3RpZmljYXRpb24gY29udGVudCBub3cuICBPbmx5IGNvbnRlbnQg Zm9yIHN1Y2ggbm90aWZpY2F0aW9ucyB0aGF0IHdlIG5lZWQgaW4gdGhlIHNob3J0IHRpbWUsIGlu IHBhcnRpY3VsYXIgcmVsYXRlZCB0byB0aGUgTkVUQ09ORiBwcm90b2NvbC4gIE90aGVyIG5vdGlm aWNhdGlvbiBjb250ZW50IGNhbiBiZSBkZWZpbmVkIG9uY2UgbmV0bW9kIGNvbWVzIHVwIHdpdGgg dXNhYmxlIG1lY2hhbmlzbXMgZm9yIGRvaW5nIHNvLg0KU2hhcm9uOiBUaGUgZG9jdW1lbnQgaGFz IHR3byBwYXJ0cy4gIE9uZSBpcyBhYm91dCBub3RpZmljYXRpb24gJ2hlYWRlcnMnLiAgVGhlIG90 aGVyIGlzIHNwZWNpZmljIHR5cGVzIG9mIG5vdGlmaWNhdGlvbnMuICBXZSBwcm9iYWJseSB3YW50 IHRvIGhhdmUgdGhvc2UgaGVhZGVycyBkZWZpbmVkIHNvb24uDQpCZXJ0OiBJdCBzZWVtcyByZWFz b25hYmxlIHRvIHN0aWNrIHRvIGFzIGxpdHRsZSBjb250ZW50IGFzIHdlIGNhbiBnZXQgYXdheSB3 aXRoLg0KU2hhcm9uOiBXZSBjYW4gcHJvdmlzaW9uYWxseSB1c2UgcGxhaW4gZW5nbGlzaCB0byBk ZXNjcmliZSB0aGlzIGluZm9ybWF0aW9uLiAgQnkgdGhlIHRpbWUgd2Ugd2lsbCBnZXQgZG9uZSwg bmV0bW9kL1lBTkcgbWF5IGJlIGluIGEgbWF0dXJlIGVub3VnaCBzdGF0ZSB0byB1c2UgaXQuDQpC ZXJ0OiBOb3RlIHRoYXQgdGhpcyBpcyB3b3JrIHRoYXQgc3RpbGwgaGFzIHRvIGJlIGNoYXJ0ZXJl ZC4NCg0KU2hvdyBvZiBoYW5kcyB3aG8gYWdyZWVzIHdpdGggYmVydCdzIGFzc2Vzc21lbnQgb2Yg cHJpb3JpdGllcy4gIE5pbmUgYWdyZWUsIFtkaXNjdXNzaW9uIGJlZm9yZSB0aGUgJ2Rpc2FncmVl JyBwb3NpdGlvbiBjb3VsZCBiZSB0YWxsaWVkXQ0KDQpEYXZlIEhhcnJpbmd0b246IFVzZSBhIHN0 YW5kYXJkIGxhbmd1YWdlIHRvIGRlZmluZSBub3RpZmljYXRpb25zIG5vdywgdGhlbiBtb3ZlIHRv IHlhbmcgb25jZSBpdCBpcyByZWFkeS4gIFlvdSBjb3VsZCBkbyBzeXNsb2cgbm90aWZpY2F0aW9u cw0Kbm93LiAgSXQgd2lsbCBiZSBkaWZmaWN1bHQgdG8gbGltaXQgeW91cnNlbGYgdG8gdGhlICdl c3NlbnRpYWwnIG5vdGlmaWNhdGlvbnMuDQpBbmR5IHByZWZlcnMgdG8gd2FpdCBmb3IgbmV0bW9k IHRvIGJlIGRvbmUgYmVmb3JlIHdvcnJ5aW5nIGFib3V0IHRoaXMuDQoNClNoYXJvbjogVGhlIGN1 cnJlbnQgZG9jdW1lbnQgZGVmaW5lcyBhIGZldyBmaWVsZHMsIGl0IHVzZXMgWE1MIFNjaGVtYSBi ZWNhdXNlIHRoYXQncyBhdmFpbGFibGUuICBEb2Vzbid0IG1pbmQgbW92aW5nIHRvIFlBTkcuICBU aGVyZSBhcmUNCm1hbnkgcGVvcGxlIGRlZmluaW5nIG5vdGlmaWNhdGlvbiBjb250ZW50IG5vdywg YW5kIHRoZXkgZG9uJ3QgdXNlIGEgc3RhbmRhcmQgaGVhZGVyLg0KTGFkYTogSXQgaXMgb2sgdG8g dXNlIGFueSBleGlzdGluZyBzcGVjaWZpY2F0aW9uIGxhbmd1YWdlIHN1Y2ggYXMgWE1MIFNjaGVt YSBvciBSZWxheE5HIHRvIGRlZmluZSB0aGUgYmFzaWMgWE1MICdibG9iJyBmb3Igbm90aWZpY2F0 aW9ucy4NCg0KQmVydDogSWYgd2UgY2FuIGxpbWl0IG91cnNlbHZlcyB0byBvbmUgb3IgdHdvIG5v dGlmaWNhdGlvbnMsIHRoZW4gdGhhdCB3b3VsZCBiZSBubyBwcm9ibGVtLg0KDQpEYXZpZCBQYXJ0 YWluOiBXZSBjYW4gdXNlIG11bHRpcGxlIHNwZWNpZmljYXRpb24gbGFuZ3VhZ2VzIGZvciBub3Rp ZmljYXRpb25zLCBvbmUgbm9ybWF0aXZlIGFuZCBvbmUgbm90LiAgVGhlbiB3aGVuIG5ldG1vZCBp cyBkb25lLA0KY2FuIHJlY29uc2lkZXIgd2hhdCB0byBkbyBhYm91dCBZQU5HIHNwZWNpZmljYXRp b24gb2YgdGhlc2Ugbm90aWZpY2F0aW9uIHR5cGVzLg0KRGFuIFJvbWFzY2FudTogV2hhdCBkb2Vz ICd3YWl0IGZvciBuZXRtb2QnIG1lYW4/DQpCZXJ0OiBTaG91bGQgYmUgZG9uZSBieSBzZXB0ZW1i ZXIgMjAwOSBvZmZpY2lhbGx5LiAgQnV0IEkgaGF2ZSBiZWVuIGluIHRoZSBJRVRGIGxvbmcgZW5v dWdoIHRvIG5vdCBjb3VudCBvbiB0aGF0LiAgVGhhdCdzIHdoeSB3ZSBzaG91bGQgbGltaXQNCm91 cnNlbGYgdG8gYSBtaW5pbWFsIHNldCBvZiBub3RpZmljYXRpb25zLiAgV2UgY2FuIHVzZSBYU0Qg b3Igd2hhdGV2ZXIuICBJJ20gbm90IGluIGZhdm9yIG9mICdsZXQncyB3YWl0IGZvciBuZXRtb2Qn Lg0KRGFuIFJvbWFzY2FudTogV2luZG93IG9mIG9wcG9ydHVuaXR5IGlzIGNsb3NpbmcsIGJ1dCBz dGlsbCB0aGVyZS4NCkJlcnQ6IEFzIFdHIGNvLWNoYWlyLCB3YW50cyBhIGdvb2QgZmVlbGluZyBh Ym91dCBmZWFzaWJpbGl0eSBiZWZvcmUgY2hhcnRlcmluZyB0aGlzIHdvcmsuDQpCYWxhc3o6IFdl IGRvbid0IG5lZWQgdG8gd2FpdCBmb3IgYSBjb21wbGV0ZSBZQU5HIGRyYWZ0IGJlZm9yZSBzdGFy dGluZyB3aXRoIHRoaXMuDQpMYWRhOiBZQU5HIHdvdWxkIGJlIGlkZWFsIGZvciB0aGlzLCBidXQg WFNEIE9yIFJlbGF4Tkcgc2VlbSBzdWZmaWNpZW50LCBhbmQgdGhleSBhcmUgdW5saWtlbHkgdG8g Y2hhbmdlIHNvb24uDQpCZXJ0OiBBIHNuYXBzaG90IG9mIFlBTkcgY291bGQgYmUgdXNlZCwF5IHRvIHNvbHZpbmcgaXQuDQoN CkxhZGE6IFNwZWNpZnksIGNhbiBpdCBiZSBzb2x2ZWQgaW4gYSB3YXkgdGhhdCBzYXRpc2ZpZXMg ZXZlcnlib2R5Pw0KDQpCZXJ0OiBJdCBzaG91bGQgYmUgcG9zc2libGUgdG8gYWNoaWV2ZSByb3Vn aCBjb25zZW5zdXMgLSB0aGVyZSBjYW4gc3RpbGwgYmUgbm9uLWludGVyb3BlcmFibGUgaW1wbGVt ZW50YXRpb25zLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk5FVENPTkYgTm90aWZpY2F0aW9uIENvbnRl bnQgLSBCZXJ0IFdpam5lbg0KDQpTbGlkZXM6IGh0dHA6Ly93d3czLmlldGYub3JnL3Byb2NlZWRp bmdzLzA4bm92L3NsaWRlcy9uZXRjb25mLTUucHB0DQoNCkJlcnQ6IFRoZSBmZWVsaW5nIHRoZSBX RyBjaGFpcnMgZ290IGZyb20gbGFzdCBpZXRmIG1lZXRpbmc6IA0KV2UgZG8gbm90IHdhbnQgdG8g ZGVmaW5lIGV4dGVuc2l2ZSBub3RpZmljYXRpb24gY29udGVudCBub3cuICBPbmx5IGNvbnRlbnQg Zm9yIHN1Y2ggbm90aWZpY2F0aW9ucyB0aGF0IHdlIG5lZWQgaW4gdGhlIHNob3J0IHRpbWUsIGlu IHBhcnRpY3VsYXIgcmVsYXRlZCB0byB0aGUgTkVUQ09ORiBwcm90b2NvbC4gIE90aGVyIG5vdGlm aWNhdGlvbiBjb250ZW50IGNhbiBiZSBkZWZpbmVkIG9uY2UgbmV0bW9kIGNvbWVzIHVwIHdpdGgg dXNhYmxlIG1lY2hhbmlzbXMgZm9yIGRvaW5nIHNvLg0KU2hhcm9uOiBUaGUgZG9jdW1lbnQgaGFz IHR3byBwYXJ0cy4gIE9uZSBpcyBhYm91dCBub3RpZmljYXRpb24gJ2hlYWRlcnMnLiAgVGhlIG90 aGVyIGlzIHNwZWNpZmljIHR5cGVzIG9mIG5vdGlmaWNhdGlvbnMuICBXZSBwcm9iYWJseSB3YW50 IHRvIGhhdmUgdGhvc2UgaGVhZGVycyBkZWZpbmVkIHNvb24uDQpCZXJ0OiBJdCBzZWVtcyByZWFz b25hYmxlIHRvIHN0aWNrIHRvIGFzIGxpdHRsZSBjb250ZW50IGFzIHdlIGNhbiBnZXQgYXdheSB3 aXRoLg0KU2hhcm9uOiBXZSBjYW4gcHJvdmlzaW9uYWxseSB1c2UgcGxhaW4gZW5nbGlzaCB0byBk ZXNjcmliZSB0aGlzIGluZm9ybWF0aW9uLiAgQnkgdGhlIHRpbWUgd2Ugd2lsbCBnZXQgZG9uZSwg bmV0bW9kL1lBTkcgbWF5IGJlIGluIGEgbWF0dXJlIGVub3VnaCBzdGF0ZSB0byB1c2UgaXQuDQpC ZXJ0OiBOb3RlIHRoYXQgdGhpcyBpcyB3b3JrIHRoYXQgc3RpbGwgaGFzIHRvIGJlIGNoYXJ0ZXJl ZC4NCg0KU2hvdyBvZiBoYW5kcyB3aG8gYWdyZWVzIHdpdGggYmVydCdzIGFzc2Vzc21lbnQgb2Yg cHJpb3JpdGllcy4gIE5pbmUgYWdyZWUsIFtkaXNjdXNzaW9uIGJlZm9yZSB0aGUgJ2Rpc2FncmVl JyBwb3NpdGlvbiBjb3VsZCBiZSB0YWxsaWVkXQ0KDQpEYXZlIEhhcnJpbmd0b246IFVzZSBhIHN0 YW5kYXJkIGxhbmd1YWdlIHRvIGRlZmluZSBub3RpZmljYXRpb25zIG5vdywgdGhlbiBtb3ZlIHRv IHlhbmcgb25jZSBpdCBpcyByZWFkeS4gIFlvdSBjb3VsZCBkbyBzeXNsb2cgbm90aWZpY2F0aW9u cw0Kbm93LiAgSXQgd2lsbCBiZSBkaWZmaWN1bHQgdG8gbGltaXQgeW91cnNlbGYgdG8gdGhlICdl c3NlbnRpYWwnIG5vdGlmaWNhdGlvbnMuDQpBbmR5IHByZWZlcnMgdG8gd2FpdCBmb3IgbmV0bW9k IHRvIGJlIGRvbmUgYmVmb3JlIHdvcnJ5aW5nIGFib3V0IHRoaXMuDQoNClNoYXJvbjogVGhlIGN1 cnJlbnQgZG9jdW1lbnQgZGVmaW5lcyBhIGZldyBmaWVsZHMsIGl0IHVzZXMgWE1MIFNjaGVtYSBi ZWNhdXNlIHRoYXQncyBhdmFpbGFibGUuICBEb2Vzbid0IG1pbmQgbW92aW5nIHRvIFlBTkcuICBU aGVyZSBhcmUNCm1hbnkgcGVvcGxlIGRlZmluaW5nIG5vdGlmaWNhdGlvbiBjb250ZW50IG5vdywg YW5kIHRoZXkgZG9uJ3QgdXNlIGEgc3RhbmRhcmQgaGVhZGVyLg0KTGFkYTogSXQgaXMgb2sgdG8g dXNlIGFueSBleGlzdGluZyBzcGVjaWZpY2F0aW9uIGxhbmd1YWdlIHN1Y2ggYXMgWE1MIFNjaGVt YSBvciBSZWxheE5HIHRvIGRlZmluZSB0aGUgYmFzaWMgWE1MICdibG9iJyBmb3Igbm90aWZpY2F0 aW9ucy4NCg0KQmVydDogSWYgd2UgY2FuIGxpbWl0IG91cnNlbHZlcyB0byBvbmUgb3IgdHdvIG5v dGlmaWNhdGlvbnMsIHRoZW4gdGhhdCB3b3VsZCBiZSBubyBwcm9ibGVtLg0KDQpEYXZpZCBQYXJ0 YWluOiBXZSBjYW4gdXNlIG11bHRpcGxlIHNwZWNpZmljYXRpb24gbGFuZ3VhZ2VzIGZvciBub3Rp ZmljYXRpb25zLCBvbmUgbm9ybWF0aXZlIGFuZCBvbmUgbm90LiAgVGhlbiB3aGVuIG5ldG1vZCBp cyBkb25lLA0KY2FuIHJlY29uc2lkZXIgd2hhdCB0byBkbyBhYm91dCBZQU5HIHNwZWNpZmljYXRp b24gb2YgdGhlc2Ugbm90aWZpY2F0aW9uIHR5cGVzLg0KRGFuIFJvbWFzY2FudTogV2hhdCBkb2Vz ICd3YWl0IGZvciBuZXRtb2QnIG1lYW4/DQpCZXJ0OiBTaG91bGQgYmUgZG9uZSBieSBzZXB0ZW1i ZXIgMjAwOSBvZmZpY2lhbGx5LiAgQnV0IEkgaGF2ZSBiZWVuIGluIHRoZSBJRVRGIGxvbmcgZW5v dWdoIHRvIG5vdCBjb3VudCBvbiB0aGF0LiAgVGhhdCdzIHdoeSB3ZSBzaG91bGQgbGltaXQNCm91 cnNlbGYgdG8gYSBtaW5pbWFsIHNldCBvZiBub3RpZmljYXRpb25zLiAgV2UgY2FuIHVzZSBYU0Qg b3Igd2hhdGV2ZXIuICBJJ20gbm90IGluIGZhdm9yIG9mICdsZXQncyB3YWl0IGZvciBuZXRtb2Qn Lg0KRGFuIFJvbWFzY2FudTogV2luZG93IG9mIG9wcG9ydHVuaXR5IGlzIGNsb3NpbmcsIGJ1dCBz dGlsbCB0aGVyZS4NCkJlcnQ6IEFzIFdHIGNvLWNoYWlyLCB3YW50cyBhIGdvb2QgZmVlbGluZyBh Ym91dCBmZWFzaWJpbGl0eSBiZWZvcmUgY2hhcnRlcmluZyB0aGlzIHdvcmsuDQpCYWxhc3o6IFdl IGRvbid0IG5lZWQgdG8gd2FpdCBmb3IgYSBjb21wbGV0ZSBZQU5HIGRyYWZ0IGJlZm9yZSBzdGFy dGluZyB3aXRoIHRoaXMuDQpMYWRhOiBZQU5HIHdvdWxkIGJlIGlkZWFsIGZvciB0aGlzLCBidXQg WFNEIE9yIFJlbGF4Tkcgc2VlbSBzdWZmaWNpZW50LCBhbmQgdGhleSBhcmUgdW5saWtlbHkgdG8g Y2hhbmdlIHNvb24uDQpCZXJ0OiBBIHNuYXBzaG90IG9mIFlBTkcgY291bGQgYmUgdgYW5k IFhTRCBvciBSZWxheE5HIGdlbmVyYXRlZCBmcm9tIHRoYXQuICBUaGUgcXVlc3Rpb24gaXMgd2hh dCBzaG91bGQgYmUgbm9ybWF0aXZlLg0KDQpEYXZpZCBQYXJ0YWluIHRha2VzIGlzc3VlIHdpdGgg dGhlIG5vdGlvbiB0aGF0IFlBTkcgaXMgYSBtb3ZpbmcgdGFyZ2V0IHRoYXQgY2Fubm90IGJlIHJl bGllZCB1cG9uLiAgSXQgaXMgYWN0dWFsbHkgcXVpdGUgdXNhYmxlIG5vdy4NCkJlcnQ6IEFuZCBp biBjYXNlIHRoZXJlIGFyZSBjaGFuZ2VzLCB3ZSBjYW4gc3RpbGwgZGVjbGFyZSB0aGUgWFNEIGFz IG5vcm1hdGl2ZS4NCg0KRGF2aWQgSGFycmluZ3RvbjogQ28tY2hhaXJzIGJvdGggbmV0bW9kIGFu ZCBzeXNsb2cuICBBIHllYXIgYWdvIHdlIGhhZCBhIHN5c2xvZyBtb2RlbCBkcmFmdCBhbmQgdGhv dWdodCBpdCB3YXMgc3RhYmxlLiAgVG9vayBhIHllYXIgdG8gZ28NCnRocm91Z2ggSUVTRyByZXZp ZXcuICBJRVNHIHJldmlldyBjYW4gZ3JlYXRseSBjaGFuZ2Ugd2hhdCBhIHNwZWNpZmljYXRpb24g bG9va3MgbGlrZS4NCg0KU2hvdyBvZiBoYW5kcyB3aG8gYWdyZWVzIHdpdGggQmVydCdzIGFzc2Vz c21lbnQgb2YgcHJpb3JpdGllcy4gIEFmdGVyIGRpc2N1c3Npb24sIG5vIG9iamVjdGlvbnMuDQpC ZXJ0OiBDb25zZW5zdXMgY2FsbCBvbiB1cmdlbnQgbm93IC0gMjAgZm9yOyAwIGRpc2FncmVlDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KV0cgQ2hhcnRlciBVcGRhdGVzDQoNCjEvMw0KDQo0NzQxYmlzIGFz IHByZXNlbnRlZCBieSBNYXJ0aW4NCi0gYnVnIGZpeGVzLCBjbGFyaWZpY2F0aW9ucywgTk8gRVhU RU5TSU9OUyAobm90IGRvaW5nIG5ldGNvbmYgVjIuMCkNCi0gc2hvdyBvZiBoYW5kcyBzaG93cyB3 aWRlIHN1cHBvcnQgYW5kIG5vIG9iamVjdGlvbnMuDQoNCkRhbiBSb21hc2NhbnUgYXNrcyBhYm91 dCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHJlcXVpcmVtZW50cw0KSnVlcmdlbjogV2UgbmVlZCB0 byBmaXggY29udHJhZGljdGlvbnMsIHRoaXMgd2lsbCBtYWtlIHNvbWUgZXhpc3RpbmcgaW1wbGVt ZW50YXRpb25zIG5vbi1jb21wbGlhbnQuDQpBbmR5IHByZWZlcnMgYSAxLjEgdGhhdCBpcyBub3Qg bmVjZXNzYXJpbHkgYmFja3dhcmQgY29tcGF0aWJsZS4gIFdoYXQgdmFsdWUgaXMgYSBuZXcgcmZj IHdpdGgganVzdCBidWcgZml4ZXM/IE5vdCB3b3J0aCB0aGUgZWZmb3J0Lg0KPz8/U2hvdyBvZiBo YW5kcyBzaG93cyB3aWRlIHN1cHBvcnQgYW5kIG5vIG9iamVjdGlvbnMuDQoNCjIvMw0KDQoid2l0 aC1kZWZhdWx0cyBjYXBhYmlsaXR5IiBhcyBwcmVzZW50ZWQgYnkgQmFsYXN6IGFuZCBBbmR5DQoN CkJlcnQncyBzdWdnZXN0aW9uOg0KLSBzbWFsbCBzdGFuZC1hbG9uZSBkb2N1bWVudA0KLSB1c2Ug ZHJhZnQtYmllcm1hbi1uZXRjb25mLXdpdGgtZGVmYXVsdHMtMDEudHh0IGFzIGJhc2UgZm9yIGEg V0cgZG9jdW1lbnQNClNob3cgb2YgaGFuZHMgc2hvd3Mgd2lkZSBzdXBwb3J0IGFuZCBubyBvYmpl Y3Rpb25zIHRvIGRvIHRoZSB3b3JrIHdpaHQgYSBzdGFuZC1hbG9uZSBkb2N1bWVudA0KQ29uc2Vu c3VzOiBTaG91bGQgdGhpcyB3b3JrIGJlIGJhc2VkIG9uIGRyYWZ0LWJpZXJtYW4tbmV0Y29uZi13 aXRoLWRlZmF1bHRzIGFzIGEgYmFzZT8gMTYgaW4gZmF2b3IsIDIgYWdhaW5zdA0KDQozLzMNCg0K Tm90aWZpY2F0aW9uIGNvbnRlbnQgKHZlcnkgbGltaXRlZCBzZXQgb2YgY29udGVudCkNCg0KQmVy dCdzIHN1Z2dlc3Rpb246DQotIERyYWZ0LWNoaXNob2xtLW5ldGNvbmYtbm90LWNvbnRlbnQtMDAu dHh0IGNhbm5vdCBiZSB1c2VkIGFzIGEgYmFzZS4NCi0gVG8gc3RhcnQgZnJvbSBiZWNhdXNlIGl0 IGlzIHRvbyBleHRlbnNpdmUuIEN1dHRpbmcgc3R1ZmYgb3V0IHJlcXVpcmVzIHRvbyBtYW55IGN5 Y2xlcy4gUHJlZmVyIG5ldyBkb2N1bWVudCBhbmQgZWRpdG9ycyBjYW4gY3V0LWFuZC1wYXN0ZSBm cm9tDQpTaGFyb24ncyBkb2N1bWVudCBhcyBkZXNpcmVkLg0KLSBXZSBuZWVkIHZvbHVudGVlcnMg Zm9yIHdyaXRpbmcgYW4gaW5pdGlhbCBkcmFmdC4gSXQgc2hvdWxkIGJlIGNsZWFyIHRvIHRob3Nl IHZvbHVudGVlcnMgdGhhdCB3ZSB3b3VsZCBsaWtlIHRoaXMgZG9uZSB3aXRoaW4sIHNheSwgc2l4 IG1vbnRocy4NCg0KU2hhcm9uIGZpbmRzIGl0IHRvbyBzdHJvbmcgdG8gc2F5IHRoYXQgZHJhZnQt Y2hpc2hvbG0gY2Fubm90IGJlIGJhc2UuDQpCZXJ0IGhhcyBubyBwcm9ibGVtcyBpZiB0aGUgbmV3 IC0wMCBkb2N1bWVudCBjb3BpZXMgc2VsZWN0ZWQgY29udGVudCBmcm9tIGRyYWZ0LWNoaXNob2xt LW5ldGNvbmYtbm90LWNvbnRlbnQtMDAuDQpTaGFyb246IFN1cmdlcnkgb2YgdGhlIGV4aXN0aW5n IGRvY3VtZW50IHRvIGZpdCB0aGUgbmV3IHJlcXVpcmVtZW50cyBzaG91bGRuJ3QgYmUgYSBwcm9i bGVtLCBhbmQgSSB3b3VsZCB2b2x1bnRlZXIgdG8gaGVscCB3aXRoIHRoaXMuDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KQmVydCAmIE1laG1ldCB0aGFuayBldmVyeWJvZHkgYW5kIGNsb3NlIHRoZSBtZWV0 aW5nLg0KDQo= ------_=_NextPart_001_01C95316.5877E722 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_01C95316.5877E722-- XNlZCwgYW5k IFhTRCBvciBSZWxheE5HIGdlbmVyYXRlZCBmcm9tIHRoYXQuICBUaGUgcXVlc3Rpb24gaXMgd2hh dCBzaG91bGQgYmUgbm9ybWF0aXZlLg0KDQpEYXZpZCBQYXJ0YWluIHRha2VzIGlzc3VlIHdpdGgg dGhlIG5vdGlvbiB0aGF0IFlBTkcgaXMgYSBtb3ZpbmcgdGFyZ2V0IHRoYXQgY2Fubm90IGJlIHJl bGllZCB1cG9uLiAgSXQgaXMgYWN0dWFsbHkgcXVpdGUgdXNhYmxlIG5vdy4NCkJlcnQ6IEFuZCBp biBjYXNlIHRoZXJlIGFyZSBjaGFuZ2VzLCB3ZSBjYW4gc3RpbGwgZGVjbGFyZSB0aGUgWFNEIGFz IG5vcm1hdGl2ZS4NCg0KRGF2aWQgSGFycmluZ3RvbjogQ28tY2hhaXJzIGJvdGggbmV0bW9kIGFu ZCBzeXNsb2cuICBBIHllYXIgYWdvIHdlIGhhZCBhIHN5c2xvZyBtb2RlbCBkcmFmdCBhbmQgdGhv dWdodCBpdCB3YXMgc3RhYmxlLiAgVG9vayBhIHllYXIgdG8gZ28NCnRocm91Z2ggSUVTRyByZXZp ZXcuICBJRVNHIHJldmlldyBjYW4gZ3JlYXRseSBjaGFuZ2Ugd2hhdCBhIHNwZWNpZmljYXRpb24g bG9va3MgbGlrZS4NCg0KU2hvdyBvZiBoYW5kcyB3aG8gYWdyZWVzIHdpdGggQmVydCdzIGFzc2Vz c21lbnQgb2YgcHJpb3JpdGllcy4gIEFmdGVyIGRpc2N1c3Npb24sIG5vIG9iamVjdGlvbnMuDQpC ZXJ0OiBDb25zZW5zdXMgY2FsbCBvbiB1cmdlbnQgbm93IC0gMjAgZm9yOyAwIGRpc2FncmVlDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KV0cgQ2hhcnRlciBVcGRhdGVzDQoNCjEvMw0KDQo0NzQxYmlzIGFz IHByZXNlbnRlZCBieSBNYXJ0aW4NCi0gYnVnIGZpeGVzLCBjbGFyaWZpY2F0aW9ucywgTk8gRVhU RU5TSU9OUyAobm90IGRvaW5nIG5ldGNvbmYgVjIuMCkNCi0gc2hvdyBvZiBoYW5kcyBzaG93cyB3 aWRlIHN1cHBvcnQgYW5kIG5vIG9iamVjdGlvbnMuDQoNCkRhbiBSb21hc2NhbnUgYXNrcyBhYm91 dCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHJlcXVpcmVtZW50cw0KSnVlcmdlbjogV2UgbmVlZCB0 byBmaXggY29udHJhZGljdGlvbnMsIHRoaXMgd2lsbCBtYWtlIHNvbWUgZXhpc3RpbmcgaW1wbGVt ZW50YXRpb25zIG5vbi1jb21wbGlhbnQuDQpBbmR5IHByZWZlcnMgYSAxLjEgdGhhdCBpcyBub3Qg bmVjZXNzYXJpbHkgYmFja3dhcmQgY29tcGF0aWJsZS4gIFdoYXQgdmFsdWUgaXMgYSBuZXcgcmZj IHdpdGgganVzdCBidWcgZml4ZXM/IE5vdCB3b3J0aCB0aGUgZWZmb3J0Lg0KPz8/U2hvdyBvZiBo YW5kcyBzaG93cyB3aWRlIHN1cHBvcnQgYW5kIG5vIG9iamVjdGlvbnMuDQoNCjIvMw0KDQoid2l0 aC1kZWZhdWx0cyBjYXBhYmlsaXR5IiBhcyBwcmVzZW50ZWQgYnkgQmFsYXN6IGFuZCBBbmR5DQoN CkJlcnQncyBzdWdnZXN0aW9uOg0KLSBzbWFsbCBzdGFuZC1hbG9uZSBkb2N1bWVudA0KLSB1c2Ug ZHJhZnQtYmllcm1hbi1uZXRjb25mLXdpdGgtZGVmYXVsdHMtMDEudHh0IGFzIGJhc2UgZm9yIGEg V0cgZG9jdW1lbnQNClNob3cgb2YgaGFuZHMgc2hvd3Mgd2lkZSBzdXBwb3J0IGFuZCBubyBvYmpl Y3Rpb25zIHRvIGRvIHRoZSB3b3JrIHdpaHQgYSBzdGFuZC1hbG9uZSBkb2N1bWVudA0KQ29uc2Vu c3VzOiBTaG91bGQgdGhpcyB3b3JrIGJlIGJhc2VkIG9uIGRyYWZ0LWJpZXJtYW4tbmV0Y29uZi13 aXRoLWRlZmF1bHRzIGFzIGEgYmFzZT8gMTYgaW4gZmF2b3IsIDIgYWdhaW5zdA0KDQozLzMNCg0K Tm90aWZpY2F0aW9uIGNvbnRlbnQgKHZlcnkgbGltaXRlZCBzZXQgb2YgY29udGVudCkNCg0KQmVy dCdzIHN1Z2dlc3Rpb246DQotIERyYWZ0LWNoaXNob2xtLW5ldGNvbmYtbm90LWNvbnRlbnQtMDAu dHh0IGNhbm5vdCBiZSB1c2VkIGFzIGEgYmFzZS4NCi0gVG8gc3RhcnQgZnJvbSBiZWNhdXNlIGl0 IGlzIHRvbyBleHRlbnNpdmUuIEN1dHRpbmcgc3R1ZmYgb3V0IHJlcXVpcmVzIHRvbyBtYW55IGN5 Y2xlcy4gUHJlZmVyIG5ldyBkb2N1bWVudCBhbmQgZWRpdG9ycyBjYW4gY3V0LWFuZC1wYXN0ZSBm cm9tDQpTaGFyb24ncyBkb2N1bWVudCBhcyBkZXNpcmVkLg0KLSBXZSBuZWVkIHZvbHVudGVlcnMg Zm9yIHdyaXRpbmcgYW4gaW5pdGlhbCBkcmFmdC4gSXQgc2hvdWxkIGJlIGNsZWFyIHRvIHRob3Nl IHZvbHVudGVlcnMgdGhhdCB3ZSB3b3VsZCBsaWtlIHRoaXMgZG9uZSB3aXRoaW4sIHNheSwgc2l4 IG1vbnRocy4NCg0KU2hhcm9uIGZpbmRzIGl0IHRvbyBzdHJvbmcgdG8gc2F5IHRoYXQgZHJhZnQt Y2hpc2hvbG0gY2Fubm90IGJlIGJhc2UuDQpCZXJ0IGhhcyBubyBwcm9ibGVtcyBpZiB0aGUgbmV3 IC0wMCBkb2N1bWVudCBjb3BpZXMgc2VsZWN0ZWQgY29udGVudCBmcm9tIGRyYWZ0LWNoaXNob2xt LW5ldGNvbmYtbm90LWNvbnRlbnQtMDAuDQpTaGFyb246IFN1cmdlcnkgb2YgdGhlIGV4aXN0aW5n IGRvY3VtZW50IHRvIGZpdCB0aGUgbmV3IHJlcXVpcmVtZW50cyBzaG91bGRuJ3QgYmUgYSBwcm9i bGVtLCBhbmQgSSB3b3VsZCB2b2x1bnRlZXIgdG8gaGVscCB3aXRoIHRoaXMuDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KQmVydCAmIE1laG1ldCB0aGFuayBldmVyeWJvZHkgYW5kIGNsb3NlIHRoZSBtZWV0 aW5nLg0KDQo= ------_=_NextPart_001_01C95316.5877E722 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_01C95316.5877E722-- From netconf-bounces@ietf.org Sun Nov 30 14:47: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 94BA33A6984; Sun, 30 Nov 2008 14:47:37 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B8428C164 for ; Sun, 30 Nov 2008 14:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 tUyHWw5ZeCym for ; Sun, 30 Nov 2008 14:47:35 -0800 (PST) Received: from mailsrv.s3group.com (tales.s3group.com [193.120.90.35]) by core3.amsl.com (Postfix) with ESMTP id 730E03A689F for ; Sun, 30 Nov 2008 14:47:34 -0800 (PST) Received: from exduba.dublin.ad.s3group.com (host-89-100.s3group.com [193.120.89.100] (may be forged)) by mailsrv.s3group.com with ESMTP id mAUMlPkx011494; Sun, 30 Nov 2008 22:47:25 GMT Received: from webmail.s3group.com ([193.120.90.34]) by exduba.dublin.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Nov 2008 22:47:25 +0000 Received: from 87.99.34.137 (SquirrelMail authenticated user tomaszmi) by webmail.s3group.com with HTTP; Sun, 30 Nov 2008 22:47:25 -0000 (GMT) Message-ID: <24552.87.99.34.137.1228085245.squirrel@webmail.s3group.com> In-Reply-To: <49304FAC.8060905@netconfcentral.com> References: <49300A02.5050105@s3group.com> <49304FAC.8060905@netconfcentral.com> Date: Sun, 30 Nov 2008 22:47:25 -0000 (GMT) From: "Tomasz Mikolajczyk" To: "Andy Bierman" User-Agent: SquirrelMail/1.4.8-6.el3 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-OriginalArrivalTime: 30 Nov 2008 22:47:25.0502 (UTC) FILETIME=[9D5D55E0:01C9533D] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (tales) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailsrv.s3group.com [193.120.90.35]); Sun, 30 Nov 2008 22:47:29 +0000 (GMT) Cc: NETCONF Subject: Re: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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: > Tomasz Mikolajczyk wrote: >> Hi, >> >> Did you consider how a NETCONF server should handle a invalid name of >> the XML tag. For instance how to handle a parameter called "1port" of >> the >> "interface" class that is defined in a managed device? The following >> hypothetical response is an invalid XML: >> >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> >> eth0 >> <1port>1234 >> >> >> >> >> >> Such parameter's name is valid from the CLI point of view. It means that >> this kind of "dynamic-like" model may introduce limitations in the >> device modeling if someone wants to use NETCONF. The foFrom netconf-bounces@ietf.org Sun Nov 30 14:47: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 94BA33A6984; Sun, 30 Nov 2008 14:47:37 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B8428C164 for ; Sun, 30 Nov 2008 14:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 tUyHWw5ZeCym for ; Sun, 30 Nov 2008 14:47:35 -0800 (PST) Received: from mailsrv.s3group.com (tales.s3group.com [193.120.90.35]) by core3.amsl.com (Postfix) with ESMTP id 730E03A689F for ; Sun, 30 Nov 2008 14:47:34 -0800 (PST) Received: from exduba.dublin.ad.s3group.com (host-89-100.s3group.com [193.120.89.100] (may be forged)) by mailsrv.s3group.com with ESMTP id mAUMlPkx011494; Sun, 30 Nov 2008 22:47:25 GMT Received: from webmail.s3group.com ([193.120.90.34]) by exduba.dublin.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Nov 2008 22:47:25 +0000 Received: from 87.99.34.137 (SquirrelMail authenticated user tomaszmi) by webmail.s3group.com with HTTP; Sun, 30 Nov 2008 22:47:25 -0000 (GMT) Message-ID: <24552.87.99.34.137.1228085245.squirrel@webmail.s3group.com> In-Reply-To: <49304FAC.8060905@netconfcentral.com> References: <49300A02.5050105@s3group.com> <49304FAC.8060905@netconfcentral.com> Date: Sun, 30 Nov 2008 22:47:25 -0000 (GMT) From: "Tomasz Mikolajczyk" To: "Andy Bierman" User-Agent: SquirrelMail/1.4.8-6.el3 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-OriginalArrivalTime: 30 Nov 2008 22:47:25.0502 (UTC) FILETIME=[9D5D55E0:01C9533D] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (tales) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailsrv.s3group.com [193.120.90.35]); Sun, 30 Nov 2008 22:47:29 +0000 (GMT) Cc: NETCONF Subject: Re: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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: > Tomasz Mikolajczyk wrote: >> Hi, >> >> Did you consider how a NETCONF server should handle a invalid name of >> the XML tag. For instance how to handle a parameter called "1port" of >> the >> "interface" class that is defined in a managed device? The following >> hypothetical response is an invalid XML: >> >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> >> eth0 >> <1port>1234 >> >> >> >> >> >> Such parameter's name is valid from the CLI point of view. It means that >> this kind of "dynamic-like" model may introduce limitations in the >> device modeling if someone wants to use NETCONF. The followinllowing >> "static-like" model can solve this problem: >> > > > Using the NETCONF standard means accepting the limitations > of the standard, which in this case is imposed by XML. > > >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> >> interface >> >> eth0 >> >> 1port >> 1234 >> >> >> >> >> >> >> > > You could internally map the CLI name to some valid XML name, > instead of this sort of double abstraction, but it is just a > DM design choice. I agree. In our product we are very flexible in such naming. In spite of this, there is always a chance that integrator may use a wrong value. >> >> The "dynamic-like" object has limited functionality, because it can show >> only a dynamic data (instances and parameters with valid values) and >> it's hard to show another kind of data like static information about >> managed_object type. By the static data I mean kind of descriptions of the objects, attributes, etc. Managed resources may have defined different descriptive data, for instance like these presented via CLI: > ospf area 10.10.10.10 stub ? default-metric Metric for the default route advertised... send-summaries Propagates summary LSAs into this stub area as-boundary Configures the CSS as an ASB router In the above command "Configures the CSS as an ASB router" may be treated as a description of the "as-boundary" attribute and displayed as a help-hint in a NETCONF client. Data models used in RFC 4741 don't mention about such data at all. Do you present them via your Data Models? >> Tomasz >> > > Andy > > Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf g >> "static-like" model can solve this problem: >> > > > Using the NETCONF standard means accepting the limitations > of the standard, which in this case is imposed by XML. > > >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> >> interface >> >> eth0 >> >> 1port >> 1234 >> >> >> >> >> >> >> > > You could internally map the CLI name to some valid XML name, > instead of this sort of double abstraction, but it is just a > DM design choice. I agree. In our product we are very flexible in such naming. In spite of this, there is always a chance that integrator may use a wrong value. >> >> The "dynamic-like" object has limited functionality, because it can show >> only a dynamic data (instances and parameters with valid values) and >> it's hard to show another kind of data like static information about >> managed_object type. By the static data I mean kind of descriptions of the objects, attributes, etc. Managed resources may have defined different descriptive data, for instance like these presented via CLI: > ospf area 10.10.10.10 stub ? default-metric Metric for the default route advertised... send-summaries Propagates summary LSAs into this stub area as-boundary Configures the CSS as an ASB router In the above command "Configures the CSS as an ASB router" may be treated as a description of the "as-boundary" attribute and displayed as a help-hint in a NETCONF client. Data models used in RFC 4741 don't mention about such data at all. Do you present them via your Data Models? >> Tomasz >> > > Andy > > Tomasz The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Nov 30 14:55: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 1A7A028C164; Sun, 30 Nov 2008 14:55:14 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8153A68CE for ; Sun, 30 Nov 2008 14:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 nGt8n1mD7nCP for ; Sun, 30 Nov 2008 14:55:11 -0800 (PST) Received: from mailsrv.s3group.com (tales.s3group.com [193.120.90.35]) by core3.amsl.com (Postfix) with ESMTP id 53FA73A6452 for ; Sun, 30 Nov 2008 14:55:11 -0800 (PST) Received: from exduba.dublin.ad.s3group.com (host-89-100.s3group.com [193.120.89.100] (may be forged)) by mailsrv.s3group.com with ESMTP id mAUMt273013049; Sun, 30 Nov 2008 22:55:02 GMT Received: from webmail.s3group.com ([193.120.90.34]) by exduba.dublin.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Nov 2008 22:55:02 +0000 Received: from 87.99.34.137 (SquirrelMail authenticated user tomaszmi) by webmail.s3group.com with HTTP; Sun, 30 Nov 2008 22:55:02 -0000 (GMT) Message-ID: <29756.87.99.34.137.1228085702.squirrel@webmail.s3group.com> In-Reply-To: <200811282106.mASL6lxD073641@idle.juniper.net> References: <200811282106.mASL6lxD073641@idle.juniper.net> Date: Sun, 30 Nov 2008 22:55:02 -0000 (GMT) From: "Tomasz Mikolajczyk" To: "Phil Shafer" User-Agent: SquirrelMail/1.4.8-6.el3 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-OriginalArrivalTime: 30 Nov 2008 22:55:02.0498 (UTC) FILETIME=[ADC16420:01C9533E] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (tales) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailsrv.s3group.com [193.120.90.35]); Sun, 30 Nov 2008 22:55:04 +0000 (GMT) Cc: NETCONF Subject: Re: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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: > Tomasz Mikolajczyk writes: >>Did you consider how a NETCONF server should handle a invalid name of the >> XML >>tag. > > Invalid XML is a protocol error. IIRC this causes the connection > to be terminated. > >>For instance how to handle a parameter called "1port" of the >>"interface" class that is defined in a managed device? > > In our DDL (the JUNOS DDL is more CLI oriented), we have a property > called "xml-name" for translating CLI into XML. For example, the > "1port" element could have an xml-name of "one-port". > > attribute 1port { > xml-name "one-port"; > ... > } However, in spite of this there is also a possibility that a wrong value may be passed as an "xml-name", but I think this case should be correctly handled by the reader of such data. > In YANG, this would work backwards, with your "one-port" leaf having > a "cli-name" property telling the CLI the term to use: > > leaf one-port { > my:cli-name "1port"; > ... > } > > Thanks, > Phil > The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Nov 30 14:55: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 1A7A028C164; Sun, 30 Nov 2008 14:55:14 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8153A68CE for ; Sun, 30 Nov 2008 14:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 nGt8n1mD7nCP for ; Sun, 30 Nov 2008 14:55:11 -0800 (PST) Received: from mailsrv.s3group.com (tales.s3group.com [193.120.90.35]) by core3.amsl.com (Postfix) with ESMTP id 53FA73A6452 for ; Sun, 30 Nov 2008 14:55:11 -0800 (PST) Received: from exduba.dublin.ad.s3group.com (host-89-100.s3group.com [193.120.89.100] (may be forged)) by mailsrv.s3group.com with ESMTP id mAUMt273013049; Sun, 30 Nov 2008 22:55:02 GMT Received: from webmail.s3group.com ([193.120.90.34]) by exduba.dublin.ad.s3group.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Nov 2008 22:55:02 +0000 Received: from 87.99.34.137 (SquirrelMail authenticated user tomaszmi) by webmail.s3group.com with HTTP; Sun, 30 Nov 2008 22:55:02 -0000 (GMT) Message-ID: <29756.87.99.34.137.1228085702.squirrel@webmail.s3group.com> In-Reply-To: <200811282106.mASL6lxD073641@idle.juniper.net> References: <200811282106.mASL6lxD073641@idle.juniper.net> Date: Sun, 30 Nov 2008 22:55:02 -0000 (GMT) From: "Tomasz Mikolajczyk" To: "Phil Shafer" User-Agent: SquirrelMail/1.4.8-6.el3 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-OriginalArrivalTime: 30 Nov 2008 22:55:02.0498 (UTC) FILETIME=[ADC16420:01C9533E] X-Scanner: InterScan AntiVirus for Sendmail X-Filter-Version: 1.11,S3-1.6 (tales) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailsrv.s3group.com [193.120.90.35]); Sun, 30 Nov 2008 22:55:04 +0000 (GMT) Cc: NETCONF Subject: Re: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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: > Tomasz Mikolajczyk writes: >>Did you consider how a NETCONF server should handle a invalid name of the >> XML >>tag. > > Invalid XML is a protocol error. IIRC this causes the connection > to be terminated. > >>For instance how to handle a parameter called "1port" of the >>"interface" class that is defined in a managed device? > > In our DDL (the JUNOS DDL is more CLI oriented), we have a property > called "xml-name" for translating CLI into XML. For example, the > "1port" element could have an xml-name of "one-port". > > attribute 1port { > xml-name "one-port"; > ... > } However, in spite of this there is also a possibility that a wrong value may be passed as an "xml-name", but I think this case should be correctly handled by the reader of such data. > In YANG, this would work backwards, with your "one-port" leaf having > a "cli-name" property telling the CLI the term to use: > > leaf one-port { > my:cli-name "1port"; > ... > } > > Thanks, > Phil > The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Nov 30 18:20: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 3A9C628C1A4; Sun, 30 Nov 2008 18:20:00 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918C428C1A6 for ; Sun, 30 Nov 2008 18:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oe7F9spaUIzS for ; Sun, 30 Nov 2008 18:19:58 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 4FC3A28C1A4 for ; Sun, 30 Nov 2008 18:19:58 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSTNJuY9lCNeBVwUn6NrjiPFtL5tw9a3y@postini.com; Sun, 30 Nov 2008 18:19:55 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Sun, 30 Nov 2008 18:18:17 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Nov 2008 18:18:16 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Nov 2008 18:18:15 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Nov 2008 18:18:15 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mB12IEM77306; Sun, 30 Nov 2008 18:18:14 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id mB12D2i4087111; Mon, 1 Dec 2008 02:13:03 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812010213.mB12D2i4087111@idle.juniper.net> To: "Tomasz Mikolajczyk" In-Reply-To: <29756.87.99.34.137.1228085702.squirrel@webmail.s3group.com> Date: Sun, 30 Nov 2008 21:13:02 -0500 From: Phil Shafer X-OriginalArrivalTime: 01 Dec 2008 02:18:15.0484 (UTC) FILETIME=[115767C0:01C9535B] MIME-Version: 1.0 Cc: NETCONF Subject: Re: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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 "Tomasz Mikolajczyk" writes: >However, in spite of this there is also a possibility that a wrong value >may be passed as an "xml-name", but I think this case should be correctly >handled by the reader of such data. If we speak in xml and you send me bad xml, the correct thing would be to flag it as bad xml and either let you know or kill the session and let someone else know (syslog). Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Nov 30 18:20: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 3A9C628C1A4; Sun, 30 Nov 2008 18:20:00 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918C428C1A6 for ; Sun, 30 Nov 2008 18:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oe7F9spaUIzS for ; Sun, 30 Nov 2008 18:19:58 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 4FC3A28C1A4 for ; Sun, 30 Nov 2008 18:19:58 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSTNJuY9lCNeBVwUn6NrjiPFtL5tw9a3y@postini.com; Sun, 30 Nov 2008 18:19:55 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Sun, 30 Nov 2008 18:18:17 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Nov 2008 18:18:16 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Nov 2008 18:18:15 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Nov 2008 18:18:15 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mB12IEM77306; Sun, 30 Nov 2008 18:18:14 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id mB12D2i4087111; Mon, 1 Dec 2008 02:13:03 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200812010213.mB12D2i4087111@idle.juniper.net> To: "Tomasz Mikolajczyk" In-Reply-To: <29756.87.99.34.137.1228085702.squirrel@webmail.s3group.com> Date: Sun, 30 Nov 2008 21:13:02 -0500 From: Phil Shafer X-OriginalArrivalTime: 01 Dec 2008 02:18:15.0484 (UTC) FILETIME=[115767C0:01C9535B] MIME-Version: 1.0 Cc: NETCONF Subject: Re: [Netconf] handling invalid XML tag name X-BeenThere: netconf@ietf.org X-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 "Tomasz Mikolajczyk" writes: >However, in spite of this there is also a possibility that a wrong value >may be passed as an "xml-name", but I think this case should be correctly >handled by the reader of such data. If we speak in xml and you send me bad xml, the correct thing would be to flag it as bad xml and either let you know or kill the session and let someone else know (syslog). Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Nov 30 23:26: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 4BFD13A6947; Sun, 30 Nov 2008 23:26:58 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B533A3A6947 for ; Sun, 30 Nov 2008 23:26:56 -0800 (PST) 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=[AWL=-0.000, 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 qUPX8P4GmEPA for ; Sun, 30 Nov 2008 23:26:56 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0344C3A6905 for ; Sun, 30 Nov 2008 23:26:56 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 6FE0176C52F; Mon, 1 Dec 2008 08:26:51 +0100 (CET) Date: Mon, 01 Dec 2008 08:26:47 +0100 (CET) Message-Id: <20081201.082647.53832166.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <492F0832.4020409@netconfcentral.com> References: <492EDB92.9020007@netconfcentral.com> <20081127.203623.123935533.mbj@tail-f.com> <492F0832.4020409@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] test-option in edit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: > I changed my mind about removing this knob. > I forgot about test-only. The default should > be set, since that is the right thing for candidate, > and the same as test-then-set for running. Maybe the default should have been 'set', for consistency reasons. But I don't think that this is a bug, so we should not change it in 4741bis. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Nov 30 23:26: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 4BFD13A6947; Sun, 30 Nov 2008 23:26:58 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B533A3A6947 for ; Sun, 30 Nov 2008 23:26:56 -0800 (PST) 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=[AWL=-0.000, 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 qUPX8P4GmEPA for ; Sun, 30 Nov 2008 23:26:56 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0344C3A6905 for ; Sun, 30 Nov 2008 23:26:56 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 6FE0176C52F; Mon, 1 Dec 2008 08:26:51 +0100 (CET) Date: Mon, 01 Dec 2008 08:26:47 +0100 (CET) Message-Id: <20081201.082647.53832166.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <492F0832.4020409@netconfcentral.com> References: <492EDB92.9020007@netconfcentral.com> <20081127.203623.123935533.mbj@tail-f.com> <492F0832.4020409@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] test-option in edit-config operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: > I changed my mind about removing this knob. > I forgot about test-only. The default should > be set, since that is the right thing for candidate, > and the same as test-then-set for running. Maybe the default should have been 'set', for consistency reasons. But I don't think that this is a bug, so we should not change it in 4741bis. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Nov 30 23:36: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 97D5B3A6881; Sun, 30 Nov 2008 23:36:25 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E459E3A6881 for ; Sun, 30 Nov 2008 23:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, 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 tOdmUA80DkcG for ; Sun, 30 Nov 2008 23:36:24 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 299103A6826 for ; Sun, 30 Nov 2008 23:36:24 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 4BDAA76C52F; Mon, 1 Dec 2008 08:36:20 +0100 (CET) Date: Mon, 01 Dec 2008 08:36:17 +0100 (CET) Message-Id: <20081201.083617.60857508.mbj@tail-f.com> To: tomasz.mikolajczyk@s3group.com From: Martin Bjorklund In-Reply-To: <492FAD64.6010600@s3group.com> References: <492FAD64.6010600@s3group.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] :candidate vs :writable-running X-BeenThere: netconf@ietf.org X-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 Tomasz Mikolajczyk wrote: > Hi, > > I read at http://www.netconfcentral.com/netconf_docs about candidate > configuration that: [...] > There is also written that: > "Agent platforms which support the :candidate capability usually do not > also support the :writable-running capability, since mixing direct > edits to would defeat the purpose of using this scratchpad > database to collect and validate changes before applying them." I don't know about others, but I do know that many (most?) of our customers have both :candidate and :writable-running. By having both, you give the choice to the client application - either make sure you're alone and work with the candidate or edit running directly. Some changes might be easier to just edit to running. > Another point is that RFC 4741 says that all the changes in the > candidate configuration have to be committed, otherwise running must > remain unchanged. What if during commit a connection with the device > would be broken, for example somebody cut the cable? How are we going to > tell the device that a kind of rollback have to be done? 4741 specifies what the server MUST do. *How* it is done is up to the implementation. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Nov 30 23:36: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 97D5B3A6881; Sun, 30 Nov 2008 23:36:25 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E459E3A6881 for ; Sun, 30 Nov 2008 23:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, 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 tOdmUA80DkcG for ; Sun, 30 Nov 2008 23:36:24 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 299103A6826 for ; Sun, 30 Nov 2008 23:36:24 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 4BDAA76C52F; Mon, 1 Dec 2008 08:36:20 +0100 (CET) Date: Mon, 01 Dec 2008 08:36:17 +0100 (CET) Message-Id: <20081201.083617.60857508.mbj@tail-f.com> To: tomasz.mikolajczyk@s3group.com From: Martin Bjorklund In-Reply-To: <492FAD64.6010600@s3group.com> References: <492FAD64.6010600@s3group.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] :candidate vs :writable-running X-BeenThere: netconf@ietf.org X-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 Tomasz Mikolajczyk wrote: > Hi, > > I read at http://www.netconfcentral.com/netconf_docs about candidate > configuration that: [...] > There is also written that: > "Agent platforms which support the :candidate capability usually do not > also support the :writable-running capability, since mixing direct > edits to would defeat the purpose of using this scratchpad > database to collect and validate changes before applying them." I don't know about others, but I do know that many (most?) of our customers have both :candidate and :writable-running. By having both, you give the choice to the client application - either make sure you're alone and work with the candidate or edit running directly. Some changes might be easier to just edit to running. > Another point is that RFC 4741 says that all the changes in the > candidate configuration have to be committed, otherwise running must > remain unchanged. What if during commit a connection with the device > would be broken, for example somebody cut the cable? How are we going to > tell the device that a kind of rollback have to be done? 4741 specifies what the server MUST do. *How* it is done is up to the implementation. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Dec 1 00:26: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 9885C3A691C; Mon, 1 Dec 2008 00:26:24 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35F483A691C for ; Mon, 1 Dec 2008 00:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=0.018, 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 XrxB0+U3QJPO for ; Mon, 1 Dec 2008 00:26:22 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5F05C3A6909 for ; Mon, 1 Dec 2008 00:26:22 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 666DB76C52F; Mon, 1 Dec 2008 09:26:18 +0100 (CET) Date: Mon, 01 Dec 2008 09:26:15 +0100 (CET) Message-Id: <20081201.092615.89733536.mbj@tail-f.com> To: tomasz.mikolajczyk@s3group.com From: Martin Bjorklund In-Reply-To: <49301058.1050609@s3group.com> References: <49301058.1050609@s3group.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] filtering notification streams X-BeenThere: netconf@ietf.org X-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 Tomasz Mikolajczyk wrote: > Hi, > > Section 3.4 from the RFC 5277 shows in the XSD schema that the > element MUST appear always once and the element MUST appear at > least once, because NETCONF server has to define always at least "NETCONF" > stream. What in your opinion a server should return as a response for > the following request: > > > > > > > > > > > ]]>]]> The server should return the streams subtree, either once or twice. It is a bit unlcear if the "filter output" is supposed to be a proper set or not. Since it is a subtree filter, it should not return an error. > Another point. The RFC says in the section 3.2.5.1: > > "Available event streams for the requesting session are returned in the reply > containing the and elements, where the > element is mandatory, and its value is unique within the scope of a NETCONF > server. An empty reply is returned if there are no available event > streams, due to user-specified filters on the operation." > > My comments to this: > 1) The "replaySupport" node is also mandatory according to the schema > 2) Seems that the empty reply doesn't match the schema The schema describes the conceptual data store, not the PUDs. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Dec 1 00:26: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 9885C3A691C; Mon, 1 Dec 2008 00:26:24 -0800 (PST) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35F483A691C for ; Mon, 1 Dec 2008 00:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=0.018, 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 XrxB0+U3QJPO for ; Mon, 1 Dec 2008 00:26:22 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5F05C3A6909 for ; Mon, 1 Dec 2008 00:26:22 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 666DB76C52F; Mon, 1 Dec 2008 09:26:18 +0100 (CET) Date: Mon, 01 Dec 2008 09:26:15 +0100 (CET) Message-Id: <20081201.092615.89733536.mbj@tail-f.com> To: tomasz.mikolajczyk@s3group.com From: Martin Bjorklund In-Reply-To: <49301058.1050609@s3group.com> References: <49301058.1050609@s3group.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] filtering notification streams X-BeenThere: netconf@ietf.org X-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 Tomasz Mikolajczyk wrote: > Hi, > > Section 3.4 from the RFC 5277 shows in the XSD schema that the > element MUST appear always once and the element MUST appear at > least once, because NETCONF server has to define always at least "NETCONF" > stream. What in your opinion a server should return as a response for > the following request: > > > > > > > > > > > ]]>]]> The server should return the streams subtree, either once or twice. It is a bit unlcear if the "filter output" is supposed to be a proper set or not. Since it is a subtree filter, it should not return an error. > Another point. The RFC says in the section 3.2.5.1: > > "Available event streams for the requesting session are returned in the reply > containing the and elements, where the > element is mandatory, and its value is unique within the scope of a NETCONF > server. An empty reply is returned if there are no available event > streams, due to user-specified filters on the operation." > > My comments to this: > 1) The "replaySupport" node is also mandatory according to the schema > 2) Seems that the empty reply doesn't match the schema The schema describes the conceptual data store, not the PUDs. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf