Capital One | Message

From owner-netconf@ops.ietf.org Thu Mar 01 00:11:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMdZg-0007aW-Kh for netconf-archive@lists.ietf.org; Thu, 01 Mar 2007 00:11:28 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMdZe-0000KJ-PB for netconf-archive@lists.ietf.org; Thu, 01 Mar 2007 00:11:28 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HMdSq-000MAn-FG for netconf-data@psg.com; Thu, 01 Mar 2007 05:04:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,HTML_90_100, HTML_MESSAGE autolearn=ham version=3.1.7 Received: from [61.144.161.54] (helo=szxga02-in.huawei.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HMdSl-000M9V-Ql for netconf@ops.ietf.org; Thu, 01 Mar 2007 05:04:22 +0000 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JE700KZJKR0QX@szxga02-in.huawei.com> for netconf@ops.ietf.org; Thu, 01 Mar 2007 13:04:12 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JE700L2BKQYM3@szxga02-in.huawei.com> for netconf@ops.ietf.org; Thu, 01 Mar 2007 13:04:12 +0800 (CST) Received: from l48181 ([10.111.12.171]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JE700EVKKQU52@szxml03-in.huawei.com> for netconf@ops.ietf.org; Thu, 01 Mar 2007 13:04:10 +0800 (CST) Date: Thu, 01 Mar 2007 13:04:06 +0800 From: Li Yan Subject: a few comments on notification-06 To: netconf@ops.ietf.org Message-id: <001301c75bbf$0a5963a0$ab0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_/vupO8yrzOd79ncHslkBww)" Thread-index: AcdbvwkV+RLsw88XSmWDSPOHRC34Lg== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.7 (/) X-Scan-Signature: 5f7f0ccb81325a1ef68017154246779c This is a multi-part message in MIME format. --Boundary_(ID_/vupO8yrzOd79ncHslkBww) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I have a few comments. o 1.2 paragraph 3, "An NETCONF server" should be "A NETCONF server". ^^ 6.1 contains a "An NETCONF server" also. o 5.2 The first example: ^^^ Parentheses don't match. o 5.2 The second example is wrong. The given filtering criteria are not consistent with the xpath filter. The first xpath clause should be removed. select="((event[eventClasses/fault] or ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ o I suggest that the naming style of elements should be identical. There are two naming style in the draft. For example, "named-profile" and "namedProfile". I prefer "xxx-yyy" to "xxxYyy". Yan --Boundary_(ID_/vupO8yrzOd79ncHslkBww) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

I have a few comments.

o 1.2 paragraph 3, "An NETCONF server" should be "A NETCONF server".

6.1 contains a "An NETCONF server" also.

o 5.2 The first example:

<netconf:filter type="xpath"

select="event/eventClasses/fault' and

(event[severity='critical'] or

event[severity='major'] or

event[severity='minor')))"/>

^^^

Parentheses don't match.

o 5.2 The second example is wrong. The given filtering criteria are not consistent with the xpath filter.

The first xpath clause should be removed.

select="((event[eventClasses/fault] or

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

o I suggest that the naming style of elements should be identical. There are two naming style in the draft. For example, "named-profile" and "namedProfile". I prefer "xxx-yyy" to "xxxYyy".

Yan

--Boundary_(ID_/vupO8yrzOd79ncHslkBww)-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Mar 01 03:21:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMgXN-00019P-Ej for netconf-archive@lists.ietf.org; Thu, 01 Mar 2007 03:21:17 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMgXM-0007c1-4A for netconf-archive@lists.ietf.org; Thu, 01 Mar 2007 03:21:17 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HMgQg-000DS0-JO for netconf-data@psg.com; Thu, 01 Mar 2007 08:14:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HMgQe-000DRQ-KY for netconf@ops.ietf.org; Thu, 01 Mar 2007 08:14:21 +0000 Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193]) by mail.tail-f.com (Postfix) with ESMTP id B068F1B80C4; Thu, 1 Mar 2007 09:14:18 +0100 (CET) Date: Thu, 01 Mar 2007 09:14:13 +0100 (CET) Message-Id: <20070301.091413.91875580.mbj@tail-f.com> To: jbalestr@cisco.com Cc: netconf@ops.ietf.org Subject: Re: am I missing some error code From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 5.1.51 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b "James Balestriere (jbalestr)" wrote: > Hi , > > Someone sends this request > > > > > > and gets an operation-failed error and starts questioning the > capabilities > my box supports. > > But, when I go through the error codes in Appendix A, I do not see any > error code > which deals with malformed XML so I have to use the catch-all > operation-failed. > I think in some cases returning operation-failed to malformed xml could > be a > bit misleading. > > Have I missed some error code somewhere which is more appropriate ? > or do we need to add one ? You can use your own . And you can also send your own structured well-defined error messages . We're using ~10 error-app-tag and corresponding error-info; nor for this particular case though. We just send a generic operation-failed with: The end tag 'copy-config' does not match the start tag 'source'. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Mar 01 20:37:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMwiX-0000aE-DM for netconf-archive@lists.ietf.org; Thu, 01 Mar 2007 20:37:53 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMwiV-0001BO-Vc for netconf-archive@lists.ietf.org; Thu, 01 Mar 2007 20:37:53 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HMwc5-000D5x-Ff for netconf-data@psg.com; Fri, 02 Mar 2007 01:31:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.7 Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HMwc3-000D4d-05 for netconf@ops.ietf.org; Fri, 02 Mar 2007 01:31:12 +0000 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 l221V7p03890; Thu, 1 Mar 2007 20:31:07 -0500 (EST) 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_01C75C6A.675BBE7C" Subject: FW: I-D ACTION:draft-chisholm-netconf-monitoring-00.txt Date: Thu, 1 Mar 2007 20:30:42 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40DB7F6D3@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-chisholm-netconf-monitoring-00.txt Thread-Index: AcdcXUspEvKLZVFERz+4pNeFIuSyMAADL+3w From: "Sharon Chisholm" To: "netconf" , "Netconf Data Model Discussion" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 This is a multi-part message in MIME format. ------_=_NextPart_001_01C75C6A.675BBE7C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Here is the draft we discussed in the last face-to-face meeting that took all the monitoring related Schema from the Notification draft and combined it with the monitoring related Schema that had been floating around to manage the base protocol. Sharon=20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Thursday, March 01, 2007 6:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-chisholm-netconf-monitoring-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NETCONF Monitoring Schema Author(s) : S. Chisholm, H. Trevino Filename : draft-chisholm-netconf-monitoring-00.txt Pages : 13 Date : 2007-3-1 =09 This document defines Netconf content via XML Schema to be used to monitor the Netconf protocol. It provides information about Netconf sessions and subscriptions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chisholm-netconf-monitoring-00 .txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-chisholm-netconf-monitoring-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-chisholm-netconf-monitoring-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C75C6A.675BBE7C Content-Type: application/octet-stream; name="ATT600533.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT600533.TXT Content-Disposition: attachment; filename="ATT600533.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNy0zLTExNTI1NTcuSS1EQGlldGYub3JnPg0KDQpFTkNP RElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtY2hpc2hvbG0tbmV0Y29uZi1t b25pdG9yaW5nLTAwLnR4dA0K ------_=_NextPart_001_01C75C6A.675BBE7C Content-Type: application/octet-stream; name="draft-chisholm-netconf-monitoring-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-chisholm-netconf-monitoring-00.URL Content-Disposition: attachment; filename="draft-chisholm-netconf-monitoring-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1jaGlzaG9sbS1uZXRjb25mLW1vbml0b3JpbmctMDAudHh0DQo= ------_=_NextPart_001_01C75C6A.675BBE7C Content-Type: text/plain; name="ATT600534.txt" Content-Transfer-Encoding: base64 Content-Description: ATT600534.txt Content-Disposition: attachment; filename="ATT600534.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C75C6A.675BBE7C-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Mar 01 21:28:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMxVx-0001jH-RL for netconf-archive@lists.ietf.org; Thu, 01 Mar 2007 21:28:57 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMxVw-0007vW-AC for netconf-archive@lists.ietf.org; Thu, 01 Mar 2007 21:28:57 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HMxRb-000GWJ-Mp for netconf-data@psg.com; Fri, 02 Mar 2007 02:24:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,SPF_SOFTFAIL, UNPARSEABLE_RELAY autolearn=no version=3.1.7 Received: from [133.145.228.44] (helo=mail9.hitachi.co.jp) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HMxRZ-000GW6-Je for netconf@ops.ietf.org; Fri, 02 Mar 2007 02:24:26 +0000 Received: from mlsv7.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id E46DC37C89 for ; Fri, 2 Mar 2007 11:24:24 +0900 (JST) Received: from mfilter-s3.hitachi.co.jp by mlsv7.hitachi.co.jp (8.12.11/8.12.11) id l222ORKu014151; Fri, 2 Mar 2007 11:24:27 +0900 Received: from vshuts5.hitachi.co.jp (unverified) by mfilter-s3.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with SMTP id ; Fri, 2 Mar 2007 11:24:24 +0900 Received: from gmml16.itg.hitachi.co.jp ([158.213.165.46]) by vshuts5.hitachi.co.jp with SMTP id M2007030211242221005 ; Fri, 02 Mar 2007 11:24:22 +0900 Received: from [127.0.0.1] by gmml16.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id l222OLn10956938; Fri, 2 Mar 2007 11:24:21 +0900 Message-ID: <45E78AD4.3010707@alaxala.net> Date: Fri, 02 Mar 2007 11:24:20 +0900 From: Yoshifumi Atarashi Organization: Alaxala Networks, Corp. User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: netconfmodel@lists.nortel.com, ops-nm@ietf.org, ngo@ietf.org, "Netconf (E-mail)" Cc: Yoshifumi Atarashi , "Ray S. Atarashi" , OKITA Hideki , t-iijima Subject: data model I-Ds Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 We wrote 3 I-Ds. First one is diffserv data model for homework of previous data model meeting. Second one is VLAN data model which will be standard document in JAPAN. Last one, we're considering possibility NETCONF systems and coordination with another systems. Title : A NETCONF Datamodel for Diff-Serv QoS Control Configuration Author(s) : H. Okita, et al. Filename : draft-okita-ngo-diffservdatamodel-00.txt Pages : 22 Date : 2007-2-27 Title : VLAN data model for NETCONF Author(s) : T. Iijima, et al. Filename : draft-iijima-ngo-vlandatamodel-00.txt Pages : 17 Date : 2007-2-27 Title : Consideration of NETCONF Architecture Author(s) : R. Atarashi, et al. Filename : draft-atarashi-ngo-consider-architecture-00.txt Pages : 32 Date : 2007-2-27 ------- Yoshifumi Atarashi -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Mar 02 04:38:42 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN4Dq-0005U1-3K for netconf-archive@lists.ietf.org; Fri, 02 Mar 2007 04:38:42 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN4Dm-0000pW-Ug for netconf-archive@lists.ietf.org; Fri, 02 Mar 2007 04:38:42 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HN46s-0005PQ-Ae for netconf-data@psg.com; Fri, 02 Mar 2007 09:31:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,HTML_90_100, HTML_MESSAGE autolearn=ham version=3.1.7 Received: from [61.144.161.53] (helo=szxga01-in.huawei.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HN46j-0005Os-Hd for netconf@ops.ietf.org; Fri, 02 Mar 2007 09:31:28 +0000 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JE900DM3ROH84@szxga01-in.huawei.com> for netconf@ops.ietf.org; Fri, 02 Mar 2007 17:29:06 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JE900LJAROGB1@szxga01-in.huawei.com> for netconf@ops.ietf.org; Fri, 02 Mar 2007 17:29:05 +0800 (CST) Received: from l48181 ([10.111.12.171]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JE900HVBROCB3@szxml03-in.huawei.com> for netconf@ops.ietf.org; Fri, 02 Mar 2007 17:29:04 +0800 (CST) Date: Fri, 02 Mar 2007 17:28:59 +0800 From: Li Yan Subject: a few comments on monitoring-00 To: 'netconf' , 'Netconf Data Model Discussion' Message-id: <000301c75cad$35a51f60$ab0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_Vv1j5q46m1kxFprGn77P6w)" Thread-index: AcdcrTU39PnXDmC7QOK4rY0PumWqRg== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.7 (/) X-Scan-Signature: 923866e691e2fd35ad8b399a2d23b59c This is a multi-part message in MIME format. --Boundary_(ID_Vv1j5q46m1kxFprGn77P6w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I have a few comments on the schema in monitoring-00. o element It has a minOccurs="0". 8.1 of rfc4741 says that each peer MUST send at least the base NETCONF capability, "urn:ietf:params:netconf:base:1.0". So minOccurs should be "1". o element It has a minOccurs="0". configuration datastore MUST be supported. So minOccurs should be "1". o element It has a minOccurs="0". The "NETCONF" notification event stream MUST be supported by a NETCONF server which supports the notification capability. So minOccurs should be "1". BTW: Does the default event stream have a normative name? Is the name "NETCONF"? o element Since the operation has already been removed from notification-draft, the element should be removed also. o complexType "NetconfSubscriptionInfo" It doesn't include and element. Yan --Boundary_(ID_Vv1j5q46m1kxFprGn77P6w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

I have a few comments on the schema in monitoring-00.

o <capability> element

It has a minOccurs="0". 8.1 of rfc4741 says that each peer MUST send at least the base NETCONF capability, "urn:ietf:params:netconf:base:1.0". So minOccurs should be "1".

o <config> element

It has a minOccurs="0". <running> configuration datastore MUST be supported. So minOccurs should be "1".

o <stream> element

It has a minOccurs="0". The "NETCONF" notification event stream MUST be supported by a NETCONF server which supports the notification capability. So minOccurs should be "1".

BTW: Does the default event stream have a normative name? Is the name "NETCONF"?

o <lastModified> element

Since the <modify-subscription> operation has already been removed from notification-draft, the element should be removed also.

o complexType "NetconfSubscriptionInfo"

It doesn't include <startTime> and <stopTime> element.

Yan

--Boundary_(ID_Vv1j5q46m1kxFprGn77P6w)-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Mar 02 08:27:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN7nc-0008Of-Sl for netconf-archive@lists.ietf.org; Fri, 02 Mar 2007 08:27:52 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN7nb-0001OA-H7 for netconf-archive@lists.ietf.org; Fri, 02 Mar 2007 08:27:52 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HN7h5-0005It-0V for netconf-data@psg.com; Fri, 02 Mar 2007 13:21:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.7 Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HN7gw-0005Gp-Vo for netconf@ops.ietf.org; Fri, 02 Mar 2007 13:21:04 +0000 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 l22DKqu12066 for ; Fri, 2 Mar 2007 08:20:52 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Comment on Notificaiton-06 Date: Fri, 2 Mar 2007 08:20:50 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40DB7F852@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comment on Notificaiton-06 Thread-Index: AcdczZjKFv//luYcRQOCP1KJya1h5g== From: "Sharon Chisholm" To: "netconf" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hi I noticed when creating the monitoring schema that it is convenient when the protocol Schema defines things as types rather then elements. It makes it easier for other schemas to just use the definition - type=3D"netconf:SessionId", for example. The Schema for the Notification definition should turn the following into types: stream named-profile Sharon Chisholm Nortel=20 Ottawa, Ontario Canada -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Mar 03 19:52:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNexx-00012p-G3 for netconf-archive@lists.ietf.org; Sat, 03 Mar 2007 19:52:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNexu-0002tz-1j for netconf-archive@lists.ietf.org; Sat, 03 Mar 2007 19:52:45 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HNerF-000CkF-GX for netconf-data@psg.com; Sun, 04 Mar 2007 00:45:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HNerD-000Cjx-8f for netconf@ops.ietf.org; Sun, 04 Mar 2007 00:45:48 +0000 Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l240jkEr019665 for ; Sat, 3 Mar 2007 19:45:46 -0500 Received: (qmail 31824 invoked by uid 78); 4 Mar 2007 00:45:45 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr4.lb.hosting.dc2.netsol.com with SMTP; 4 Mar 2007 00:45:45 -0000 Message-ID: <45EA16A5.2020205@andybierman.com> Date: Sat, 03 Mar 2007 16:45:25 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Netconf (E-mail)" , NETCONF Goes On Subject: Impact of XSD design on NETCONF operations Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Hi, Without trying to start an actual data modeling discussion, I want to point out some data model examples in the NETCONF protocol itself that impact implementations. 1) Use of choice vs. complexType(choice) Here is the rpcOperationTargetType and parameter set from RFC 4741: Use of the test-option element requires the :validate capability. Use of the url element requires the :url capability. Note that there is one more layer in the path name to get to the choice in the 'target' parameter, as opposed to the 'config or url' choice directly in the editConfigType. IMO, the first approach (complexType) is better than the 'inline choice' approach for NETCONF. Since 'target' is a stable element in a fixed position in the tree, it is simpler to generate elements (e.g., missing-element error -- is it for 'config' or 'url'? Pick one at random? Always pick the first one?) Also, access control configuration is safer if the extra (top) layer is there, in the event new choices are added to a data model in the future. With the first approach, a rule for /rpc/edit-config/target will cover any variant of that parameter. Twice as many ACL entries (/rpc/edit-config/config and /rpc/edit-config/url) would be needed with the other approach. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Mar 09 02:15:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPZKY-0001oD-JS for netconf-archive@lists.ietf.org; Fri, 09 Mar 2007 02:15:58 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPZKX-0001Zm-6b for netconf-archive@lists.ietf.org; Fri, 09 Mar 2007 02:15:58 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HPZCf-00006n-St for netconf-data@psg.com; Fri, 09 Mar 2007 07:07:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,SUBJ_HAS_UNIQ_ID autolearn=ham version=3.1.7 Received: from [61.144.161.53] (helo=szxga01-in.huawei.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HPZCc-00006S-Ia for netconf@ops.ietf.org; Fri, 09 Mar 2007 07:07:48 +0000 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JEM009O6JSWRB@szxga01-in.huawei.com> for netconf@ops.ietf.org; Fri, 09 Mar 2007 15:07:44 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JEM00IIKJSVOC@szxga01-in.huawei.com> for netconf@ops.ietf.org; Fri, 09 Mar 2007 15:07:44 +0800 (CST) Received: from m03573B ([10.111.12.160]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JEM00889JSR4M@szxml03-in.huawei.com> for netconf@ops.ietf.org; Fri, 09 Mar 2007 15:07:43 +0800 (CST) Date: Fri, 09 Mar 2007 15:07:39 +0800 From: Ma Yuzhi Subject: One comment on netconf-notification-transport-01 In-reply-to: To: netconf@ops.ietf.org Message-id: <028201c76219$a014f160$a00c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcdbmwXgcUNDEfudTvizH+1dx0Iy4QGe9HYA Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac The exmple in section 2.1 have some redundant tags, such as , and . > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Thursday, March 01, 2007 7:50 AM > To: i-d-announce@ietf.org > Subject: I-D > ACTION:draft-trevino-netconf-notification-transport-01.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : NETCONF Notification Transport Mappings > Author(s) : S. Chisholm, H. Trevino > Filename : > draft-trevino-netconf-notification-transport-01.txt > Pages : 14 > Date : 2007-2-28 > > This document defines the transport mappings for NETCONF event > notifications. This is an optional capability built on top of the > base NETCONF protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-trevino-netconf-noti > fication-transport-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of > the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-trevino-netconf-notification-transport-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-trevino-netconf-notification-transport-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Mar 09 10:02:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPgbp-0007xM-VW for netconf-archive@lists.ietf.org; Fri, 09 Mar 2007 10:02:17 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPgbk-0000i8-Ej for netconf-archive@lists.ietf.org; Fri, 09 Mar 2007 10:02:17 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HPgUq-000GKj-H3 for netconf-data@psg.com; Fri, 09 Mar 2007 14:55:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SUBJ_HAS_UNIQ_ID autolearn=ham version=3.1.7 Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HPgUh-000GIf-Vw for netconf@ops.ietf.org; Fri, 09 Mar 2007 14:54:59 +0000 Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l29Estvl011297 for ; Fri, 9 Mar 2007 09:54:55 -0500 Received: (qmail 15735 invoked by uid 78); 9 Mar 2007 14:54:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr2.lb.hosting.dc2.netsol.com with SMTP; 9 Mar 2007 14:54:55 -0000 Message-ID: <45F17529.2090007@andybierman.com> Date: Fri, 09 Mar 2007 06:54:33 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ma Yuzhi CC: netconf@ops.ietf.org Subject: Re: One comment on netconf-notification-transport-01 References: <028201c76219$a014f160$a00c6f0a@china.huawei.com> In-Reply-To: <028201c76219$a014f160$a00c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Ma Yuzhi wrote: > The exmple in section 2.1 have some redundant tags, such as , > and . Please note that this is not a WG document. We have an open issue wrt/ the transport mappings. Only SSH is supported for notifications at this time. The BEEP profile for Notification support does not exist. The detailed document describing how the SOAP transport works, including how the SOAP transport makes the Notification system work exactly the same for higher layer protocols as SSH does, does not exist. The document you cite does not contain any normative text relevant to the title of the document. It contains non-normative examples mostly taken from other documents. The WG must decide what to do (if anything) about supporting BEEP and SOAP for Notifications. I am most concerned about getting the Notifications draft completed, and do not want to block that document to wait for normative BEEP and SOAP transport mappings. There does appear to be enough interest in the WG to work on this aspect of the new protocol feature. Andy > >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: Thursday, March 01, 2007 7:50 AM >> To: i-d-announce@ietf.org >> Subject: I-D >> ACTION:draft-trevino-netconf-notification-transport-01.txt >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> >> >> Title : NETCONF Notification Transport Mappings >> Author(s) : S. Chisholm, H. Trevino >> Filename : >> draft-trevino-netconf-notification-transport-01.txt >> Pages : 14 >> Date : 2007-2-28 >> >> This document defines the transport mappings for NETCONF event >> notifications. This is an optional capability built on top of the >> base NETCONF protocol. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-trevino-netconf-noti >> fication-transport-01.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in >> the body of >> the message. >> You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-trevino-netconf-notification-transport-01.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE >> /internet-drafts/draft-trevino-netconf-notification-transport-01.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant >> mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Mar 09 10:32:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPh4u-0006xE-DZ for netconf-archive@lists.ietf.org; Fri, 09 Mar 2007 10:32:20 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPh4s-0006vY-Rw for netconf-archive@lists.ietf.org; Fri, 09 Mar 2007 10:32:20 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HPh0Z-000Jyx-AX for netconf-data@psg.com; Fri, 09 Mar 2007 15:27:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [204.127.225.96] (helo=alnrmhc16.comcast.net) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HPh0W-000Jyf-Sj for netconf@ops.ietf.org; Fri, 09 Mar 2007 15:27:50 +0000 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc16) with SMTP id <20070309152748b16008ihrve>; Fri, 9 Mar 2007 15:27:48 +0000 From: "David B Harrington" To: "'Andy Bierman'" , "'Ma Yuzhi'" Cc: References: <028201c76219$a014f160$a00c6f0a@china.huawei.com> <45F17529.2090007@andybierman.com> Subject: netconf-notification-transport-01 Date: Fri, 9 Mar 2007 10:23:29 -0500 Message-ID: <0ef401c7625e$e4a93210$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-index: AcdiW+4gy60zuSpDRCO1S5OXE0YzoQAAlukQ In-reply-to: <45F17529.2090007@andybierman.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Should the abstract be changed from "This document defines the transport mappings" to "This document defines optional transport mappings"? > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > > Please note that this is not a WG document. > We have an open issue wrt/ the transport mappings. > Only SSH is supported for notifications at this time. > [...] > The document [] does not contain any normative text > relevant to the title of the document. It contains > non-normative examples mostly taken from other documents. [...] > > Andy > > > > >> -----Original Message----- > >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >> Sent: Thursday, March 01, 2007 7:50 AM > >> To: i-d-announce@ietf.org > >> Subject: I-D > >> ACTION:draft-trevino-netconf-notification-transport-01.txt > >> > >> A New Internet-Draft is available from the on-line > >> Internet-Drafts directories. > >> > >> > >> Title : NETCONF Notification Transport Mappings > >> Author(s) : S. Chisholm, H. Trevino > >> Filename : > >> draft-trevino-netconf-notification-transport-01.txt > >> Pages : 14 > >> Date : 2007-2-28 > >> > >> This document defines the transport mappings for NETCONF event > >> notifications. This is an optional capability built on > top of the > >> base NETCONF protocol. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-trevino-netconf-noti > >> fication-transport-01.txt > >> > >> To remove yourself from the I-D Announcement list, send a > message to > >> i-d-announce-request@ietf.org with the word unsubscribe in > >> the body of > >> the message. > >> You can also visit > >> https://www1.ietf.org/mailman/listinfo/I-D-announce > >> to change your subscription settings. > >> > >> Internet-Drafts are also available by anonymous FTP. Login > with the > >> username "anonymous" and a password of your e-mail address. After > >> logging in, type "cd internet-drafts" and then > >> "get draft-trevino-netconf-notification-transport-01.txt". > >> > >> A list of Internet-Drafts directories can be found in > >> http://www.ietf.org/shadow.html > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> Internet-Drafts can also be obtained by e-mail. > >> > >> Send a message to: > >> mailserv@ietf.org. > >> In the body type: > >> "FILE > >> > /internet-drafts/draft-trevino-netconf-notification-transport-01.txt". > >> > >> NOTE: The mail server at ietf.org can return the document in > >> MIME-encoded form by using the "mpack" utility. To use this > >> feature, insert the command "ENCODING mime" before the "FILE" > >> command. To decode the response(s), you will need "munpack" or > >> a MIME-compliant mail reader. Different MIME-compliant > >> mail readers > >> exhibit different behavior, especially when dealing with > >> "multipart" MIME messages (i.e. documents which have been split > >> up into multiple messages), so check your local documentation on > >> how to manipulate these messages. > >> > >> Below is the data which will enable a MIME compliant mail reader > >> implementation to automatically retrieve the ASCII version of the > >> Internet-Draft. > >> > > > > > > > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Mar 09 12:45:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPj9Q-00067e-Kr for netconf-archive@lists.ietf.org; Fri, 09 Mar 2007 12:45:08 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPj5S-00077O-3p for netconf-archive@lists.ietf.org; Fri, 09 Mar 2007 12:41:07 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HPixW-000Bqn-0w for netconf-data@psg.com; Fri, 09 Mar 2007 17:32:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.7 Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HPixM-000Bom-Eh for netconf@ops.ietf.org; Fri, 09 Mar 2007 17:32:48 +0000 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 l29HWaA17161 for ; Fri, 9 Mar 2007 17:32:36 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: netconf-notification-transport-01 Date: Fri, 9 Mar 2007 12:32:26 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40DDA1E5A@zcarhxm2.corp.nortel.com> In-Reply-To: <0ef401c7625e$e4a93210$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: netconf-notification-transport-01 Thread-Index: AcdiW+4gy60zuSpDRCO1S5OXE0YzoQAAlukQAAR/weA= References: <028201c76219$a014f160$a00c6f0a@china.huawei.com> <45F17529.2090007@andybierman.com> <0ef401c7625e$e4a93210$0600a8c0@china.huawei.com> From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Hi This document is a holding place for the issue of transport mapping for notifications. My hope is that any gaps we identify in the existing transport mappings will result in a bis of those documents to properly cover notifications. Hector and I want to make sure the issue didn't get lost - hence the draft. If it does continue in its current form, I don't think throwing the word optional in is helpful. Either it is defining the mapping for the various transports or it isn't. I sent some private emails to ping the authors of the various transport mappings on the topic. We received some good feedback so far on SOAP (what we have in the document isn't what is needed) and a promise for a review on BEEP. Sharon=20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of David B Harrington Sent: Friday, March 09, 2007 10:23 AM To: 'Andy Bierman'; 'Ma Yuzhi' Cc: netconf@ops.ietf.org Subject: netconf-notification-transport-01 Should the abstract be changed from "This document defines the transport mappings" to "This document defines optional transport mappings"? > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >=20 > Please note that this is not a WG document. > We have an open issue wrt/ the transport mappings. > Only SSH is supported for notifications at this time. >=20 [...] > The document [] does not contain any normative text relevant to the=20 > title of the document. It contains non-normative examples mostly=20 > taken from other documents. [...] >=20 > Andy >=20 > >=20 > >> -----Original Message----- > >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >> Sent: Thursday, March 01, 2007 7:50 AM > >> To: i-d-announce@ietf.org > >> Subject: I-D > >> ACTION:draft-trevino-netconf-notification-transport-01.txt > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts=20 > >> directories. > >> > >> > >> Title : NETCONF Notification Transport Mappings > >> Author(s) : S. Chisholm, H. Trevino > >> Filename :=20 > >> draft-trevino-netconf-notification-transport-01.txt > >> Pages : 14 > >> Date : 2007-2-28 > >> =09 > >> This document defines the transport mappings for NETCONF event > >> notifications. This is an optional capability built on > top of the > >> base NETCONF protocol. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-trevino-netconf-noti > >> fication-transport-01.txt > >> > >> To remove yourself from the I-D Announcement list, send a > message to > >> i-d-announce-request@ietf.org with the word unsubscribe in the body > >> of the message. > >> You can also visit > >> https://www1.ietf.org/mailman/listinfo/I-D-announce > >> to change your subscription settings. > >> > >> Internet-Drafts are also available by anonymous FTP. Login > with the > >> username "anonymous" and a password of your e-mail address. After > >> logging in, type "cd internet-drafts" and then=20 > >> "get draft-trevino-netconf-notification-transport-01.txt". > >> > >> A list of Internet-Drafts directories can be found in > >> http://www.ietf.org/shadow.html=20 > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> Internet-Drafts can also be obtained by e-mail. > >> > >> Send a message to: > >> mailserv@ietf.org. > >> In the body type: > >> "FILE=20 > >>=20 > /internet-drafts/draft-trevino-netconf-notification-transport-01.txt". > >> =09 > >> NOTE: The mail server at ietf.org can return the document in > >> MIME-encoded form by using the "mpack" utility. To use this > >> feature, insert the command "ENCODING mime" before the "FILE" > >> command. To decode the response(s), you will need "munpack" or > >> a MIME-compliant mail reader. Different MIME-compliant=20 > >> mail readers > >> exhibit different behavior, especially when dealing with > >> "multipart" MIME messages (i.e. documents which have been split > >> up into multiple messages), so check your local documentation on > >> how to manipulate these messages. > >> > >> Below is the data which will enable a MIME compliant mail reader > >> implementation to automatically retrieve the ASCII version of the > >> Internet-Draft. > >> > >=20 > >=20 > >=20 > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > >=20 > >=20 >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Mar 09 13:05:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPjTI-0003gT-Kp for netconf-archive@lists.ietf.org; Fri, 09 Mar 2007 13:05:40 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPjTH-0003KC-2n for netconf-archive@lists.ietf.org; Fri, 09 Mar 2007 13:05:40 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HPjMr-000EnD-3C for netconf-data@psg.com; Fri, 09 Mar 2007 17:59:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.7 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HPjMZ-000Ek8-DX for netconf@ops.ietf.org; Fri, 09 Mar 2007 17:58:51 +0000 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-2.cisco.com with ESMTP; 09 Mar 2007 09:58:43 -0800 X-IronPort-AV: i="4.14,268,1170662400"; d="scan'208"; a="364917707:sNHT76483920" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l29Hwggc004415; Fri, 9 Mar 2007 09:58:42 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l29HwgxR024948; Fri, 9 Mar 2007 17:58:42 GMT Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 09:58:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: netconf-notification-transport-01 Date: Fri, 9 Mar 2007 09:58:41 -0800 Message-ID: <6E21698722408147BEA594E073E2B0AB0361CE52@xmb-sjc-223.amer.cisco.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40DDA1E5A@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: netconf-notification-transport-01 Thread-Index: AcdiW+4gy60zuSpDRCO1S5OXE0YzoQAAlukQAAR/weAAAPwA4A== References: <028201c76219$a014f160$a00c6f0a@china.huawei.com> <45F17529.2090007@andybierman.com> <0ef401c7625e$e4a93210$0600a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B40DDA1E5A@zcarhxm2.corp.nortel.com> From: "Hector Trevino $htrevino$" To: "Sharon Chisholm" , X-OriginalArrivalTime: 09 Mar 2007 17:58:42.0771 (UTC) FILETIME=[93245A30:01C76274] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5885; t=1173463122; x=1174327122; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=htrevino@cisco.com; z=From:=20=22Hector=20Trevino=20$htrevino$=22=20 |Subject:=20RE=3A=20netconf-notification-transport-01 |Sender:=20; bh=Xs8fbfr0ZfKvv3TVBAaH9THxvHKG/dMD//JX/Rqkgv8=; b=TBh4OiO0Aa3IgtFIrO2GL6TNMAaCpAk5A4Mq17oJK8tWtisAsPVy4xuing00aFhjoRm5tSU4 POFROYTJDDfflPHO7juuwu8evPkTyP5Husc28/t6v9pQ278Wuv4F8/N+; Authentication-Results: sj-dkim-7; header.From=htrevino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 And just to emphasize what Sharon says about the bis of the transport mapping documents, the following is included in the introduction: "Editor's Note: Inclusion of Notification transport mappings into bis versions of the SSH, SOAP and HTTP transport mappings RFCs should be considered instead of publishing a Notification-specific transport mapping document." Hector -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm Sent: Friday, March 09, 2007 10:32 AM To: netconf@ops.ietf.org Subject: RE: netconf-notification-transport-01 Hi This document is a holding place for the issue of transport mapping for notifications. My hope is that any gaps we identify in the existing transport mappings will result in a bis of those documents to properly cover notifications. Hector and I want to make sure the issue didn't get lost - hence the draft. If it does continue in its current form, I don't think throwing the word optional in is helpful. Either it is defining the mapping for the various transports or it isn't. I sent some private emails to ping the authors of the various transport mappings on the topic. We received some good feedback so far on SOAP (what we have in the document isn't what is needed) and a promise for a review on BEEP. Sharon=20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of David B Harrington Sent: Friday, March 09, 2007 10:23 AM To: 'Andy Bierman'; 'Ma Yuzhi' Cc: netconf@ops.ietf.org Subject: netconf-notification-transport-01 Should the abstract be changed from "This document defines the transport mappings" to "This document defines optional transport mappings"? > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >=20 > Please note that this is not a WG document. > We have an open issue wrt/ the transport mappings. > Only SSH is supported for notifications at this time. >=20 [...] > The document [] does not contain any normative text relevant to the=20 > title of the document. It contains non-normative examples mostly=20 > taken from other documents. [...] >=20 > Andy >=20 > >=20 > >> -----Original Message----- > >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >> Sent: Thursday, March 01, 2007 7:50 AM > >> To: i-d-announce@ietf.org > >> Subject: I-D > >> ACTION:draft-trevino-netconf-notification-transport-01.txt > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts=20 > >> directories. > >> > >> > >> Title : NETCONF Notification Transport Mappings > >> Author(s) : S. Chisholm, H. Trevino > >> Filename :=20 > >> draft-trevino-netconf-notification-transport-01.txt > >> Pages : 14 > >> Date : 2007-2-28 > >> =09 > >> This document defines the transport mappings for NETCONF event > >> notifications. This is an optional capability built on > top of the > >> base NETCONF protocol. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-trevino-netconf-noti > >> fication-transport-01.txt > >> > >> To remove yourself from the I-D Announcement list, send a > message to > >> i-d-announce-request@ietf.org with the word unsubscribe in the body > >> of the message. > >> You can also visit > >> https://www1.ietf.org/mailman/listinfo/I-D-announce > >> to change your subscription settings. > >> > >> Internet-Drafts are also available by anonymous FTP. Login > with the > >> username "anonymous" and a password of your e-mail address. After > >> logging in, type "cd internet-drafts" and then "get=20 > >> draft-trevino-netconf-notification-transport-01.txt". > >> > >> A list of Internet-Drafts directories can be found in=20 > >> http://www.ietf.org/shadow.html or=20 > >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> Internet-Drafts can also be obtained by e-mail. > >> > >> Send a message to: > >> mailserv@ietf.org. > >> In the body type: > >> "FILE > >>=20 > /internet-drafts/draft-trevino-netconf-notification-transport-01.txt". > >> =09 > >> NOTE: The mail server at ietf.org can return the document in > >> MIME-encoded form by using the "mpack" utility. To use this > >> feature, insert the command "ENCODING mime" before the "FILE" > >> command. To decode the response(s), you will need "munpack" or > >> a MIME-compliant mail reader. Different MIME-compliant mail=20 > >> readers > >> exhibit different behavior, especially when dealing with > >> "multipart" MIME messages (i.e. documents which have been split > >> up into multiple messages), so check your local documentation on > >> how to manipulate these messages. > >> > >> Below is the data which will enable a MIME compliant mail reader=20 > >> implementation to automatically retrieve the ASCII version of the=20 > >> Internet-Draft. > >> > >=20 > >=20 > >=20 > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with=20 > > the word 'unsubscribe' in a single line as the message text body. > > archive: > >=20 > >=20 >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with the > word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Mar 10 10:51:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ3rT-0005MN-F8 for netconf-archive@lists.ietf.org; Sat, 10 Mar 2007 10:51:59 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ3rS-0005e4-3h for netconf-archive@lists.ietf.org; Sat, 10 Mar 2007 10:51:59 -0500 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQ3hT-0009SQ-V2 for netconf-data@psg.com; Sat, 10 Mar 2007 15:41:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [205.178.146.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQ3hR-0009S5-Fa for netconf@ops.ietf.org; Sat, 10 Mar 2007 15:41:39 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l2AFfaDK002937 for ; Sat, 10 Mar 2007 10:41:36 -0500 Received: (qmail 14053 invoked by uid 78); 10 Mar 2007 15:41:36 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 10 Mar 2007 15:41:36 -0000 Message-ID: <45F2D19A.902@andybierman.com> Date: Sat, 10 Mar 2007 07:41:14 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Martin Bjorklund CC: jbalestr@cisco.com, netconf@ops.ietf.org Subject: Re: am I missing some error code References: <20070301.091413.91875580.mbj@tail-f.com> In-Reply-To: <20070301.091413.91875580.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Martin Bjorklund wrote: > "James Balestriere (jbalestr)" wrote: >> Hi , >> >> Someone sends this request >> >> >> >> >> >> and gets an operation-failed error and starts questioning the >> capabilities >> my box supports. >> >> But, when I go through the error codes in Appendix A, I do not see any >> error code >> which deals with malformed XML so I have to use the catch-all >> operation-failed. >> I think in some cases returning operation-failed to malformed xml could >> be a >> bit misleading. >> >> Have I missed some error code somewhere which is more appropriate ? >> or do we need to add one ? > > You can use your own . And you can also send your own > structured well-defined error messages . We're using ~10 > error-app-tag and corresponding error-info; nor for this particular > case though. We just send a generic operation-failed with: > > > The end tag 'copy-config' does not match the start tag 'source'. > > Sorry I missed this thread -- this is simply an 'unknown-element' error, because it is an unexpected element, which is defined in a confusing way: Tag: unknown-element Error-type: rpc, protocol, application Severity: error Error-info: : name of the unexpected element Description: An unexpected element is present. > > /martin Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Mar 11 14:46:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQT3b-0001SM-Eb for netconf-archive@lists.ietf.org; Sun, 11 Mar 2007 14:46:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQT3Z-0000PW-PA for netconf-archive@lists.ietf.org; Sun, 11 Mar 2007 14:46:11 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQSwD-0007YC-2S for netconf-data@psg.com; Sun, 11 Mar 2007 18:38:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQShO-0005N2-Mk for netconf@ops.ietf.org; Sun, 11 Mar 2007 18:23:16 +0000 Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l2BIND6A032422 for ; Sun, 11 Mar 2007 14:23:13 -0400 Received: (qmail 1388 invoked by uid 78); 11 Mar 2007 18:23:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr2.lb.hosting.dc2.netsol.com with SMTP; 11 Mar 2007 18:23:13 -0000 Message-ID: <45F448FA.4060801@andybierman.com> Date: Sun, 11 Mar 2007 11:22:50 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Comments on draft-ietf-netconf-notification-06 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Hi, I am not sure how many of these comments are duplicates from other reviewers. We'll sort that out before the WG meeting at IETF #68. In general, I think the draft is almost done, and hopefully we can resolve all the minor open issues soon. There comments are in page order, and range from typos to design flaws... - pg 3, ToC: Suggest title change of sec. 3.4 'Subscriptions not Configuration Data' - pg 3, ToC: Sec. 5 title : Capitalize examples - pg 3, ToC: No entry for IANA Considerations (no section either) - pg 4, middle of page: Move 'Figure 1' above the para, and directly below the figure - p4 4. sec. 1.1 Terms Managed Object is unclear, not used anywhere, should be removed - p5 Terms Operation: 2nd sentence is not true. Term used as stated only in sentence 1. - p5 sec1.2: Put first para in Terms section as 'Event' - pg 7, bottom: missing period after parameter - pg 7 - 8: General comments on create-subscription - need to specify conceptual data types for all parameters in this section - need to show usage examples in this section - need to combine entire section 6 (Replay) into this section since it is confusing to introduce just the parameters but not the feature. - once again, we are creating parameter dependencies that XSD cannot represent. (Just as happy to rant against XSD than change things though ;-) - pg 8, Start Time and Stop Time comments - What if a legal start-time (or start/stop pair) specifies some time in the future? - What if the timezone is given and it is not the same as the agent's timezone? - What if a time change (e.g., daylight savings time) happens? - Explain how both parameters handle forward and backward boundary conditions - pg 8, sec 2.1.1, Negative Response This section is correct, but inconsistent with the text in sec. 6.1, para 3. There is no mention of a 'warning-and-continue' mode of operation here. (More reason why sec 6. create-sub. details needs to be integrated into this section.) - pg 9, sec 2.3, Terminating the Subscription - Does the have to come from another session? (I think so) - IMO, since we do not have an endless RPC reply model, it is not a burden to the agent to accept a from the session getting notifications - Does sentence 2 mean after the last replayed notification that meets the stop time criteria, the session is terminated? - last sentence, capitalize Netconf to NETCONF - pg 10, sec 3.1.2, cap. exchange example IMO, this section should be removed. Sec. 3.1.1 defines the capability identifier. Just say that RFC 4741 defines the capability exchange. - pg 11, diagram This is a good diagram but there should be text following it explaining all the boxes, why they are there, and where in this document the relevant definitions can be found - pg 11, 3.2.1-2, typos - s/via NETCONF protocol/via the NETCONF protocol/ - missing period after last sentence - s/i.e. the notification/i.e., the notification/ - pg 11, sec 3.2.3, Default Event Stream Mentions the "NETCONF" notification event stream but this is not defined anywhere. Need to put this in the IANA considerations section that will be added. - pg 12, typos - para 1, s/e.g. SNMP, syslog, etc./e.g., SNMP, syslog/ - para 3, missing space after and before operation - pg 12, Name Retrieval comments - Need introduction and formal description of the data model for retrieving stream names - Can we use just one namespace for all NETCONF data model objects, put the definition in IANA, and use it for notification data? - agree with comment to change to for better consistency with rest of this doc, and RFC 4741. - pg 13, bad XML style end tags on new line introduces significant whitespace into the element content - pg 13, sec 3.2.5.2, redundant section This section is confusing to read, and does not really add any value, since the previous section just defined event subscription. - pg 14-15, XSD comments - should define the new verbs to be in the NETCONF base namespace and use the capability to determine whether to use it (like all other NC operations) - do not need to import these 3 namespaces - should define 1 namespace for data models related to the NETCONF protocol, not a separate namespace for every bit of monitoring data. - do not need 'stream' parameter; it is already in the RPC - do not need the read-only timestamp. This is just general metadata associated with the configuration database. We should have a general notification if this is so important. IMO, it is not important, and also a bad idea to copy this aspect of MIB design. - can we use short prefixes, like 'nc' instead of 'netconf'? - pg 16, sec 3.4 Not clear why this section is here. It is actually incorrect. If a proprietary configuration data model (or future standard) exists, then this section is wrong. - pg 17, sec 3.5 First sentence is wrong; multiple filters cannot be combined. - pg 17, 3.5.2 Term 'just-in-time filtering' is used here without any explanation what it is, or why it matters in this document. - pg 18, message flow diagram Should mention (and show) that many rpc/rpc-reply sequences could occur before the create-subscription. In fact, text suggests use of get(event-streams) first. - pg 19, XSD comments Apply same changes wrt/ namespaces, imports, and prefixes - pg 20, XSD typo Indentation of is wrong - pg 22-26, sec. 6 Move entire section to a non-normative appendix and state clearly that the data models shown are examples, not standards (bugs found by others in examples not confirmed) - pg 27, sec 6 Replay Should move all details to sec 2.1.1 - pg 27, sec 6.1, para 2 Is this warning-then-continue mode really needed? Why not just send the replay-complete notification right away, and not special-case any parameters. Bad filter data is just a no-match, not an error. - pg 28, error-tags We cannot update RFC 4741 to add redundant specialized error codes. We already have 'invalid-value'. IMO, these should not even be errors. If the supplied timestamps are well-formed, but produce no output, then this is an empty data set. - pg 28, error handling design The manager and agent procedures can both be simplified here. If the parameters are well-formed, but produce no matches, then this is no different than if the filter removed everything and there was no output. In both cases, just sent the replay-complete notification right away, instead of any warnings or errors. If a stop-time is specified, then the normal termination procedure is followed after the replay-complete is sent. - pg 29, XSD comments - do not need a special namespace for the replay-complete notification - suggest simple name like 'replay-complete' instead of 'replayCompleteNotification'. This appears in instance documents - eventClass element introduces data model details into this document that the WG has not agreed to - eventClass is an empty element with no data type or content. Doubt that is what is intended. - do not need statistics collection and reporting in this notification - do not need a timeGenerated timestamp here. The manager's receive timestamp is good enough, considering that the content or time of this notification is irrelevant. The manager just needs a marker to signal the end of replay. (That was the functional requirement.) - agree with Martin that a simple empty notification element called is sufficient:

- even if numberEventsReplayed was useful, it should be a bounded integer like 'unsignedInt' or 'unsignedLong', not integer. 2^^64 log entries is a large enough amount to cover most implementations ;-) - pg 30, Security Considerations - remove 'use of , only want to document the threats from this document, not RFC 4741. - fully specify the exact security threat, exact parameter names, use cases, etc. - fully specify which data model content is writable and identify any threats to services due to notification delivery on a NETCONF session. (Are there any? - explain that the notification content is outside the scope of this document but care must be taken just as with SNMP Notifications - explain how notifications are handled by the agent in the presence of access control. Is the entire notification dropped if only some of the included data is not allowed, or just the classified data removed from the notification? - capitalize netconf to NETCONF in last sentence - pg 30, missing IANA Considerations section - need to determine exact IANA requests and add them here -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Mar 11 15:13:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQTUP-0007zK-Kc for netconf-archive@lists.ietf.org; Sun, 11 Mar 2007 15:13:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQTUN-0003vh-DL for netconf-archive@lists.ietf.org; Sun, 11 Mar 2007 15:13:53 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQTPe-0009zm-9G for netconf-data@psg.com; Sun, 11 Mar 2007 19:08:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [205.178.146.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQTPZ-0009zU-4t for netconf@ops.ietf.org; Sun, 11 Mar 2007 19:08:55 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l2BJ8qZZ005450 for ; Sun, 11 Mar 2007 15:08:52 -0400 Received: (qmail 28238 invoked by uid 78); 11 Mar 2007 19:08:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 11 Mar 2007 19:08:51 -0000 Message-ID: <45F453AD.1090807@andybierman.com> Date: Sun, 11 Mar 2007 12:08:29 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Notification Issue List -- DRAFT Content-Type: multipart/mixed; boundary="------------070107050606090704090406" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9c747b02957c409d00ef4f5a343ba495 This is a multi-part message in MIME format. --------------070107050606090704090406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I concatenated and numbered all the mailing list comments on notification-05 and -06. I will be working during the week before the meeting to identify all the closed issues. Hopefully, just a short list of open issues will remain by next week. (If possible, can the reviewers who made specific comments help identify status, open vs. closed. vs fix-known, edit-pending, etc.) The comments are 'Numbered Inputs', from I1 to I105. Andy --------------070107050606090704090406 Content-Type: text/plain; name="notif_issue_list.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="notif_issue_list.txt" Martin Bjorklund: 12/28/06, comments on -05, checked against -06: I1) edit - resolved o 3.2.5.1 (fixed - para removed in -06) The second paragraph seems to be redundant (same info as in the first paragraph). I2) named profiles combined with filter parameter - open o 3.4 (now 3.5) The text says: Note that when multiple filters are specified, they are applied collectively, I suspect this text is no longer correct, since named profiles and filters are mutually exclusive (for some reason). --> Multiple filters are not supported in the schema This would be introducing a new type of filtering in the protocol, which is out of scope. This sentence should be removed --> Is this multiple instances of 1 param, or combining param and profile, or both? I3) replay error codes - open Need to limit error-tag values to existing values in RFC 4741 o 6.2 It is not obvious if a start-time-too-early error will create the subscription or not. If create-subscription fails with a start-time-too-early, it will be very difficult for a manager to get all logged notifications (and practically impossible to know when he got them all). --> text says rpc-error is returned, but it is called a warning. --> this seems inconsistent with other NETCONF operations which --> use some sort of filter. They return 'empty data' instead --> of an error. If start-time-too-early does not fail the create-subscription request, how does start-stop-time-mismatch work? --> Error conditions should be explained in the text section, --> not just the summary Also, is start-stop-time-mismatch really needed? Can't we just re-use 'invalid-value' (or 'bad-element') from rfc4741? --> Agree!! Do not need new error code points for this, which --> would require an update to RFC 4741. I4) replay timestamps -- open o 6.2 The text says: Note that while a notification has three potential times associated it - the time it was generated, the time it was logged and the time it was sent out by the NETCONF server - the startTime and stopTime parameters are related to generation time. I still think it will be difficult for an implementation to conform to this -- it means that the logging subsystem must either be given the generation time along with the notification itself, or be able to extract the time from the notification content. This might not always be possible. --> Agree; this is part of the content layer (as determined at --> the interim meeting I5a) replay complete filtered out -- fixed o 6.3 The text should probably state that the replayCompleteNotification is not affected by any filters on the subscription. Are eventClass, timeGenerated and numberEventsReplayed really needed? Can't we just use: I5b) exact structure of replayComplete notification -- open And a few XML errors: I6) namespace assignments -- open o 3.2.5.1 (now 3.3) The namespace of eventStreams is wrong: ^^^^^^^^^^^ both in the request and the reply. I7a) targetNamespace assignment -- open o 3.2.5.2 (now 3.3) The schema should define a targetNamespace. I7b) bug -- fixed The prefix 'nm' is not declared. (But maybe the 'nm'-elements should be removed). I8) o 5.1 & 5.2 The prefix 'netconf' is undeclared in all examples. ^^^^^^^ I9) o 5.2 Here's 'neb' again, now transformed into an undeclared prefix! If "neb:" is removed from the xpath expressions, it will be ok. I10) The schema for Named Profiles has been removed. It seems a bit odd that this mechanism is defined as configuration data, but no schema (data model) exists for manipulating these Named Profiles. ----------------------- Andy Bierman - 1/2/07 comment on -05 I11) Keep named profiles? Are they fully defined? There are essentially 2 solution paths here: 1) remove named profiles completely. The RPC method parameters are always passed at invocation time, without storing some of them 'offline' in a named-profile. 2) define a proper standard data-model for the named profile contents, which is accessible to the standard operations (e.g., edit-config, get-config), and rooted at a specific point in the Netconf Standard Data Tree (that doesn't exist yet). I thought we agreed on (2) awhile ago. Perhaps this was just over-active cut-and-paste editing. ------------------------ Li Yan 1/5/07 comment on -05 I12) o 3.2.5.2 I13) o 4 Should the two schemaLocation be the same? ---------------------------- Andy Bierman 1/5/07 comment on -05 I14) (1) extra appinfo -- fixed Sec 3.2.5.2 of notification-05 contains a stream retrieval schema with an appinfo element that is relying on the non-existent 'netmod template' standard. NetconfNotificationSchema 2006-09-06T09:30:47-05:00 IETF A schema that can be used to learn about current event streams. All of this 'extra' info should be put in a element or removed, like the XSD in section 4. I15) (2) I think the filter examples in sec. 5 need some sort of explanation of the assumed data model (i.e., the one with 'eventClasses' and 'card' as top-level siblings). ---------------------------- Balazs Lengyel - 1/9/07 -- comment on -05 I16) General: I thought we agreed on having just one schema instead of many small ones, but if must I can live with this. I17) Chapter 1.2) Please describe that any RPC requests received on a notification session may be discarded silently, without any response message. I18) Chapter 2.3) Mention termination due to closing the transport session or stop-time. I19) Chapter 3.2.5.2 Here in the nm:Name element we have NetconfNotificationSchema which is not describing the content of this specific schema. I20) Chapter 3.3) "While it is possible ..." We do not provide a schema to retrieve this information, so I would formulate this as "While it might be possible ..." I21) Chapter 6.2) Start and stop times should relate to generation time "whenever possible". Shouldn't we send back in the error info the date/time of the earliest available notification. I22) Chapter 6.3) Please indicate what happens with the session after the replayComplete notification is sent. Is it terminated on transport level? Does it become a normal session? Is it some kind of stale/ useless session? What options might a device choose? I feel terminate SSH/SOAP/BEEP is the best. ------------------------------------------ Tom Petch 2/15/07 comment on -05 I23) I see unmatched single quote and right hand bracket in the xpath; I am innocent in the ways of xpath but imagine that they might not be ok either. I24) I see no reference in the text to xpath and no such reference listed in 9. ---------------------------------------------- Sharon Chisholm 2/16/07 proposed edit list The following is the proposed set of edits to the Notification draft to resolve comments received. It may not reflect recently received comments. 1. Put back schema to create and query named profiles, except combine into single schema with the one for event stream discovery. (Source: Martin & Andy) 2. In section 1.2, indicate that RPCs requests received on a notification session may be discarded silently. (Source: Balazs) 3. In section 2.3, indicate that termination may also result from termination of the underlying transport session or reaching a stop time on a replay. (Source: Balazs) 4. In section 3.2.5, delete the first sentence of the second paragraph and merge the second sentence with the first paragraph. (Source: Martin) 5. In section 3.2.5.2, fix namespace. (Source: Martin) 6. In section 3.2.5.2, delete the appInfo reference to netmod tags. (Source: Andy, others) 7. In section 3.2.5.2, fix the schemaLocation to be the proper urn. (source Li Yan) 8. In section 3.3.3, replace "While it is possible" with "While it may be possible". (Source: Balazs) 9. In section 3.4, there is some confusion between individual filter criteria (severity=major) and the collective set of filters one gets in a named profile or with in-line filters. In checking with the base protocol specification, I think the terms should be filter element and filter respectively. The section (and perhaps other parts of the document) will be updated to consistently use these terms to clear things up. (Source: Martin) 10. In section 5, update/add explanation of data model assumptions to the filter examples (Source: Andy) 11. In section 5.1 and 5.2, fix Schema errors. (Source: Martin) 12. In section 5.2, remove the neb prefix. (Source: Martin) 11. In section 6.2, replace the Error-info for start-time-too-early with ": Timestamp of earliest event available for replay". (Source: Balazs; Martin) 12. In section 6.2, add text indicating that in the event of a warning, the event subscription is still created. (Source Martin). Note I also propose changing the severity of start-stop-time-mismatch to an error instead of a warning. 13. In section 6.3, indicate that after the replayComplete notification is sent, the session then becomes a normal Netconf session. (Source: Balazs) 14. In section 6.3, indicate that the replayCompleteNotification can not be filtered out. (Source Martin) -------------------------------------------- Tom Petch 2/16/07 comment on -05 I25) well-formed XML - closed MUST the event be properly formed XML? I imagine it must but do not see that explicitly spelt out in the I-D. Equally, MUST there be a DTD or Schema for an event? (Response from Sharon 2/20/07) It must be well-formed XML. I had been thinking that this was covered, but since we are not re-using rpc messaging for Notifications anymore, I guess we need to explicitly state it. I don't think we can make any more specific claims in this document, but certain can in data model related ones. --------------------------------------------- Balazs Lengyel - 2/22/07 -- comment on -06 Generally the document is in good shape, I could except it as is, but still I have some comments: I26) 1.) Consider adding: content of notification messages is out of scope. I27) 1.2 paragraph 2) The sentence starting with "These event notifications..." might need some rewording. I28) 2.1.1) An example could be useful. I29) 2.2.1) An example could be useful. I30) 3.2.5.1) Change title to Stream Retrieval ... I31) 3.3) Why do we need more then one namespace? I feel we should put everything into one. I32) 3.5) Remove first sentence. There can be only one filter. I33) 5.1) The sample event list is hard to understand. I would rather like to know which bit of XML will go into each event. Is it the element as a whole or just the contents of ? The example on page 24 indicates only the contents, the example on page 25 indicates the whole . The two examples contradict each other. I34) 5.1 page 25) In my understanding the example is faulty. The last clause is useless as the first fault clause will always let through all "faults". The first clause should be removed. I35) 6.2) I would mention that in replay sessions events are always sent in order of their timestamps. Events occurring during a replay will not be sent immediately, but only after all previous events are sent. --------------------------------------------------------- Tom Petch 2/23/07 comment on -06 I36) Xpath bugs -- missed edit -- fix pending I am looking at section 5.2 and seeing which appears to have seven single quotes, one left hand round bracket and three right hand round brackets, three left hand square brackets and two right hand square brackets. Response from Hector Trevino (2/23/07) Hi, I was looking at your comment and noticed that this section (5.2) was not get updated properly. We'll update. ------------------------------------------------------ Martin Bjorklund: 2/25/06, comments on -06: I37) o 3.2.5.1 Uses the URI "urn:ietf:params:xml:ns:netmod:base:1.0" for event streams in the example. But the schema in 3.3 uses "urn:ietf:params:xml:ns:netmod:event:1.0". These should be the same. I suggest that this info is put into the "urn:ietf:params:xml:ns:netconf:notification:1.0" schema. I38) o 3.3 /namedProfiles/namedProfile/name xs:key is not used for namedProfile/name. If it's not unique or a key, then there can be several namedProfiles with the same name. I suspect this is not the intention. The text in 3.2.5.1 says that the value is unique. Maybe that is sufficient. It also says about 'name' that it is modifiable. How is this supposed to be done over NETCONF? (how do you modifify the key? or even worse if it's not a key). I39) o 3.3 /namedProfiles/namedProfile/stream Why is this element included here? A stream is always specified in the (or defaults to NETCONF) when a namedProfile is used. Are these supposed to match?? I40) o 3.3 /namedProfiles/namedProfile/filter This element has a minOccurs="0". It means that the element may or may not be present in an instance document. Why is it used here? I41) o 5.1 The text shows a sample event list which doesn't match the examples that follows. I also don't understand the container. I suggest that the container is removed, and is changed to in this list. The second example must also be modified to match this. I42) o 5.1 and 5.2 All four examples use an undeclared prefix "netconf" on the element 'filter' (it shouldn't be there; 'filter' is defined in the new namespace), and lacks a xmlns attribute. Both xpath examples use the element name 'eventClasses' but the text and other examples use 'eventClass'. I43) o 6.1 Section 2.1.1 says that an element is returned for a if the request can be satisfied. This section (6.1) says "If a client requests a replay of notifications that predate the oldest notification available, then the NETCONF server must return a warning message in the RPC reply and start replaying the notifications it does have available" But, according to 4.4 of rfc4741, "The element is sent in messages if no errors or warnings occurred during the processing of an request." This is also consistent with the XML schema in rfc4741. Thus, it is not possible to return and a warning. I suppose the intention of 6.1 is that a warning only (i.e no element) is returned. The text in 2.1.1 should be updated to reflect this. I44) o 6.2 This section lists additional "Negative Response" to . I think these should be moved to 2.1.1, where is defined. Also, two new error-tags are defined. If I understand the schema in rfc4741 correctly, it is not possible to define new error-tags. An error-app-tag can be used though. Also, I don't think start-stop-time-mismatch is needed - the standard 'invalid-value' can be used. I45) o 6.3 I think that the replayCompleteNotifcation should be defined in the "urn:ietf:params:xml:ns:netconf:notification:1.0" schema. I.e. use a single schema (instead of three) for everything. Other Minor issues: I46) o 1.2 "A capability may be advertised to announce that a server is able to process RPCs while a notification stream is active on a session." Should this text really be here? There is no such capability defined. I47) o 2.1.1 "until the subscription to terminates." ^^^ ?? I48) o 3.2.5.2 This section (including 3.2.5.2.1) seems to be redundant. Compare with 2.1.1. I49) o 3.3 The schema uses xs:import to import a namespace which isn't used (1998/namespace), and two imports with a bad (?) schemaLocation. The prefix ncEvent is defined but not used. The documentation for namedProfile: "A named profile, which is a saved set of parameters associated that may be associated with zero or more active ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ?? subscriptions." I50) o 3.3 You're using two top-level elements in this schema. This means that you can't create a single standalone XML instance document which lists the eventStreams and namedProfiles (since an XML document must have a single top-level element). This isn't an error per se, but I thought I should mention it. I51) o 3.5 "Note that when multiple filters are specified," Multiple filters cannot be defined anymore, right? I52) o 4 The xs:import in this schema seems to be copy-and-pasted from thee netconf schema. It is not needed here. -------------------------------------------- Martin Bjorklund: 2/26/06, comments on -06: I53) In 6.2, about the warning message, it says Error-info: : Timestamp of earliest event available for replay This element (log-starttime) should be defined in the schema. Also, the short description could be clarified. What exactly does "available for replay" mean? Does it mean available using the filters and access rules currently in effect? I assume it does not, since if it did, the warning would be pretty useless - the same info will be included in the first event replayed. ------------------------------------------ Li Yan 2/28/07 comment on -06 I54) o 1.2 paragraph 3, "An NETCONF server" should be "A NETCONF server". ^^ 6.1 contains a "An NETCONF server" also. I55) o 5.2 The first example: ^^^ Parentheses don't match. I56) o 5.2 The second example is wrong. The given filtering criteria are not consistent with the xpath filter. The first xpath clause should be removed. select="((event[eventClasses/fault] or ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I57) element naming style -- open o I suggest that the naming style of elements should be identical. There are two naming style in the draft. For example, "named-profile" and "namedProfile". I prefer "xxx-yyy" to "xxxYyy". --> agree --------------------------------------------------- Sharon Chisholm 3/2/07 comment on -06 I58) I noticed when creating the monitoring schema that it is convenient when the protocol Schema defines things as types rather then elements. It makes it easier for other schemas to just use the definition - type="netconf:SessionId", for example. The Schema for the Notification definition should turn the following into types: stream named-profile ------------------------------------------- Andy Bierman 3/11/07 comment on -06 In general, I think the draft is almost done, and hopefully we can resolve all the minor open issues soon. There comments are in page order, and range from typos to design flaws... I59) - pg 3, ToC: Suggest title change of sec. 3.4 'Subscriptions not Configuration Data' I60) - pg 3, ToC: Sec. 5 title : Capitalize examples I61) - pg 3, ToC: No entry for IANA Considerations (no section either) I62) - pg 4, middle of page: Move 'Figure 1' above the para, and directly below the figure I63) - p4 4. sec. 1.1 Terms Managed Object is unclear, not used anywhere, should be removed I64) - p5 Terms Operation: 2nd sentence is not true. Term used as stated only in sentence 1. I65) - p5 sec1.2: Put first para in Terms section as 'Event' I66) - pg 7, bottom: missing period after parameter I67) - pg 7 - 8: General comments on create-subscription I68) - need to specify conceptual data types for all parameters in this section I69) - need to show usage examples in this section I70) - need to combine entire section 6 (Replay) into this section since it is confusing to introduce just the parameters but not the feature. I71) - once again, we are creating parameter dependencies that XSD cannot represent. (Just as happy to rant against XSD than change things though ;-) I72) - pg 8, Start Time and Stop Time comments I73) - What if a legal start-time (or start/stop pair) specifies some time in the future? I74) - What if the timezone is given and it is not the same as the agent's timezone? I75) - What if a time change (e.g., daylight savings time) happens? - Explain how both parameters handle forward and backward boundary conditions I76) - pg 8, sec 2.1.1, Negative Response This section is correct, but inconsistent with the text in sec. 6.1, para 3. There is no mention of a 'warning-and-continue' mode of operation here. (More reason why sec 6. create-sub. details needs to be integrated into this section.) - pg 9, sec 2.3, Terminating the Subscription I77) - Does the have to come from another session? (I think so) I78) - IMO, since we do not have an endless RPC reply model, it is not a burden to the agent to accept a from the session getting notifications I79) - Does sentence 2 mean after the last replayed notification that meets the stop time criteria, the session is terminated? I80) - last sentence, capitalize Netconf to NETCONF I81) - pg 10, sec 3.1.2, cap. exchange example IMO, this section should be removed. Sec. 3.1.1 defines the capability identifier. Just say that RFC 4741 defines the capability exchange. I82) - pg 11, diagram This is a good diagram but there should be text following it explaining all the boxes, why they are there, and where in this document the relevant definitions can be found I83) - pg 11, 3.2.1-2, typos - s/via NETCONF protocol/via the NETCONF protocol/ - missing period after last sentence - s/i.e. the notification/i.e., the notification/ I84) - pg 11, sec 3.2.3, Default Event Stream Mentions the "NETCONF" notification event stream but this is not defined anywhere. Need to put this in the IANA considerations section that will be added. I85) - pg 12, typos - para 1, s/e.g. SNMP, syslog, etc./e.g., SNMP, syslog/ - para 3, missing space after and before operation - pg 12, Name Retrieval comments I86) - Need introduction and formal description of the data model for retrieving stream names I87) - Can we use just one namespace for all NETCONF data model objects, put the definition in IANA, and use it for notification data? I88) - agree with comment to change to for better consistency with rest of this doc, and RFC 4741. I89) - pg 13, bad XML style end tags on new line introduces significant whitespace into the element content I90) - pg 13, sec 3.2.5.2, redundant section This section is confusing to read, and does not really add any value, since the previous section just defined event subscription. I91) - pg 14-15, XSD comments - should define the new verbs to be in the NETCONF base namespace and use the capability to determine whether to use it (like all other NC operations) - do not need to import these 3 namespaces - should define 1 namespace for data models related to the NETCONF protocol, not a separate namespace for every bit of monitoring data. - do not need 'stream' parameter; it is already in the RPC - do not need the read-only timestamp. This is just general metadata associated with the configuration database. We should have a general notification if this is so important. IMO, it is not important, and also a bad idea to copy this aspect of MIB design. - can we use short prefixes, like 'nc' instead of 'netconf'? I92) - pg 16, sec 3.4 Not clear why this section is here. It is actually incorrect. If a proprietary configuration data model (or future standard) exists, then this section is wrong. I93) - pg 17, sec 3.5 First sentence is wrong; multiple filters cannot be combined. I94) - pg 17, 3.5.2 Term 'just-in-time filtering' is used here without any explanation what it is, or why it matters in this document. I95) - pg 18, message flow diagram Should mention (and show) that many rpc/rpc-reply sequences could occur before the create-subscription. In fact, text suggests use of get(event-streams) first. I96) - pg 19, XSD comments Apply same changes wrt/ namespaces, imports, and prefixes I97) - pg 20, XSD typo Indentation of is wrong I98) - pg 22-26, sec. 6 Move entire section to a non-normative appendix and state clearly that the data models shown are examples, not standards (bugs found by others in examples not confirmed) I99) - pg 27, sec 6 Replay Should move all details to sec 2.1.1 I100) - pg 27, sec 6.1, para 2 Is this warning-then-continue mode really needed? Why not just send the replay-complete notification right away, and not special-case any parameters. Bad filter data is just a no-match, not an error. I101) - pg 28, error-tags We cannot update RFC 4741 to add redundant specialized error codes. We already have 'invalid-value'. IMO, these should not even be errors. If the supplied timestamps are well-formed, but produce no output, then this is an empty data set. I102) - pg 28, error handling design The manager and agent procedures can both be simplified here. If the parameters are well-formed, but produce no matches, then this is no different than if the filter removed everything and there was no output. In both cases, just sent the replay-complete notification right away, instead of any warnings or errors. If a stop-time is specified, then the normal termination procedure is followed after the replay-complete is sent. I103) - pg 29, XSD comments - do not need a special namespace for the replay-complete notification - suggest simple name like 'replay-complete' instead of 'replayCompleteNotification'. This appears in instance documents - eventClass element introduces data model details into this document that the WG has not agreed to - eventClass is an empty element with no data type or content. Doubt that is what is intended. - do not need statistics collection and reporting in this notification - do not need a timeGenerated timestamp here. The manager's receive timestamp is good enough, considering that the content or time of this notification is irrelevant. The manager just needs a marker to signal the end of replay. (That was the functional requirement.) - agree with Martin that a simple empty notification element called is sufficient:

- even if numberEventsReplayed was useful, it should be a bounded integer like 'unsignedInt' or 'unsignedLong', not integer. 2^^64 log entries is a large enough amount to cover most implementations ;-) I104) - pg 30, Security Considerations - remove 'use of , only want to document the threats from this document, not RFC 4741. - fully specify the exact security threat, exact parameter names, use cases, etc. - fully specify which data model content is writable and identify any threats to services due to notification delivery on a NETCONF session. (Are there any? - explain that the notification content is outside the scope of this document but care must be taken just as with SNMP Notifications - explain how notifications are handled by the agent in the presence of access control. Is the entire notification dropped if only some of the included data is not allowed, or just the classified data removed from the notification? - capitalize netconf to NETCONF in last sentence I105) - pg 30, missing IANA Considerations section - need to determine exact IANA requests and add them here ---------------------------------------------------- --------------070107050606090704090406-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Mar 11 23:55:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQbdP-0004if-Af for netconf-archive@lists.ietf.org; Sun, 11 Mar 2007 23:55:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQbdL-0005R9-Vw for netconf-archive@lists.ietf.org; Sun, 11 Mar 2007 23:55:43 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQbVE-000LxE-2s for netconf-data@psg.com; Mon, 12 Mar 2007 03:47:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [216.82.253.51] (helo=mail153.messagelabs.com) by psg.com with smtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQbUc-000Lw1-NE for netconf@ops.ietf.org; Mon, 12 Mar 2007 03:46:41 +0000 X-VirusChecked: Checked X-Env-Sender: ietf@andybierman.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1173671197!4483767!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 23959 invoked from network); 12 Mar 2007 03:46:37 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-12.tower-153.messagelabs.com with SMTP; 12 Mar 2007 03:46:37 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l2C3kXlO008076 for ; Sun, 11 Mar 2007 22:46:37 -0500 (CDT) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l2C3kWuN002672 for ; Sun, 11 Mar 2007 22:46:32 -0500 (CDT) Received: from de01exm69.ds.mot.com (de01exm69.am.mot.com [10.176.8.25]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l2C3kUS9002632 for ; Sun, 11 Mar 2007 22:46:31 -0500 (CDT) Received: from mail pickup service by de01exm69.ds.mot.com with Microsoft SMTPSVC; Sun, 11 Mar 2007 23:46:02 -0400 Received: from az33exr04.mot.com ([10.64.251.234]) by de01exm69.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Sun, 11 Mar 2007 15:10:49 -0400 Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l2BJAfJv013961; Sun, 11 Mar 2007 14:10:41 -0500 (CDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by motgate5.mot.com (8.12.11/Motorola) with SMTP id l2BJAeIX021961; Sun, 11 Mar 2007 12:10:40 -0700 (MST) X-VirusChecked: Checked X-Env-Sender: owner-netconf@ops.ietf.org X-Msg-Ref: server-10.tower-119.messagelabs.com!1173640232!13827447!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [147.28.0.62] X-SpamReason: No, hits=1.0 required=7.0 tests=bad_helo: HELO w.w not associated with this mail,BODY_RANDOM_LONG Received: (qmail 12046 invoked from network); 11 Mar 2007 19:10:36 -0000 Received: from psg.com (HELO psg.com) (147.28.0.62) by server-10.tower-119.messagelabs.com with AES256-SHA encrypted SMTP; 11 Mar 2007 19:10:36 -0000 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQTPe-0009zm-9G for netconf-data@psg.com; Sun, 11 Mar 2007 19:08:58 +0000 Received: from [205.178.146.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQTPZ-0009zU-4t for netconf@ops.ietf.org; Sun, 11 Mar 2007 19:08:55 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l2BJ8qZZ005450 for ; Sun, 11 Mar 2007 15:08:52 -0400 Received: (qmail 28238 invoked by uid 78); 11 Mar 2007 19:08:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 11 Mar 2007 19:08:51 -0000 Message-ID: <45F453AD.1090807@andybierman.com> Date: Sun, 11 Mar 2007 12:08:29 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Notification Issue List -- DRAFT Content-Type: multipart/mixed; boundary="------------070107050606090704090406" X-OriginalArrivalTime: 11 Mar 2007 19:10:50.0557 (UTC) FILETIME=[FB8796D0:01C76410] X-Vontu: Pass Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: f08e78ca11d3665672faaf95e9d79578 This is a multi-part message in MIME format. --------------070107050606090704090406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I concatenated and numbered all the mailing list comments on notification-05 and -06. I will be working during the week before the meeting to identify all the closed issues. Hopefully, just a short list of open issues will remain by next week. (If possible, can the reviewers who made specific comments help identify status, open vs. closed. vs fix-known, edit-pending, etc.) The comments are 'Numbered Inputs', from I1 to I105. Andy ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ --------------070107050606090704090406 Content-Type: text/plain; name="notif_issue_list.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="notif_issue_list.txt" Martin Bjorklund: 12/28/06, comments on -05, checked against -06: I1) edit - resolved o 3.2.5.1 (fixed - para removed in -06) The second paragraph seems to be redundant (same info as in the first paragraph). I2) named profiles combined with filter parameter - open o 3.4 (now 3.5) The text says: Note that when multiple filters are specified, they are applied collectively, I suspect this text is no longer correct, since named profiles and filters are mutually exclusive (for some reason). --> Multiple filters are not supported in the schema This would be introducing a new type of filtering in the protocol, which is out of scope. This sentence should be removed --> Is this multiple instances of 1 param, or combining param and profile, or both? I3) replay error codes - open Need to limit error-tag values to existing values in RFC 4741 o 6.2 It is not obvious if a start-time-too-early error will create the subscription or not. If create-subscription fails with a start-time-too-early, it will be very difficult for a manager to get all logged notifications (and practically impossible to know when he got them all). --> text says rpc-error is returned, but it is called a warning. --> this seems inconsistent with other NETCONF operations which --> use some sort of filter. They return 'empty data' instead --> of an error. If start-time-too-early does not fail the create-subscription request, how does start-stop-time-mismatch work? --> Error conditions should be explained in the text section, --> not just the summary Also, is start-stop-time-mismatch really needed? Can't we just re-use 'invalid-value' (or 'bad-element') from rfc4741? --> Agree!! Do not need new error code points for this, which --> would require an update to RFC 4741. I4) replay timestamps -- open o 6.2 The text says: Note that while a notification has three potential times associated it - the time it was generated, the time it was logged and the time it was sent out by the NETCONF server - the startTime and stopTime parameters are related to generation time. I still think it will be difficult for an implementation to conform to this -- it means that the logging subsystem must either be given the generation time along with the notification itself, or be able to extract the time from the notification content. This might not always be possible. --> Agree; this is part of the content layer (as determined at --> the interim meeting I5a) replay complete filtered out -- fixed o 6.3 The text should probably state that the replayCompleteNotification is not affected by any filters on the subscription. Are eventClass, timeGenerated and numberEventsReplayed really needed? Can't we just use: I5b) exact structure of replayComplete notification -- open And a few XML errors: I6) namespace assignments -- open o 3.2.5.1 (now 3.3) The namespace of eventStreams is wrong: ^^^^^^^^^^^ both in the request and the reply. I7a) targetNamespace assignment -- open o 3.2.5.2 (now 3.3) The schema should define a targetNamespace. I7b) bug -- fixed The prefix 'nm' is not declared. (But maybe the 'nm'-elements should be removed). I8) o 5.1 & 5.2 The prefix 'netconf' is undeclared in all examples. ^^^^^^^ I9) o 5.2 Here's 'neb' again, now transformed into an undeclared prefix! If "neb:" is removed from the xpath expressions, it will be ok. I10) The schema for Named Profiles has been removed. It seems a bit odd that this mechanism is defined as configuration data, but no schema (data model) exists for manipulating these Named Profiles. ----------------------- Andy Bierman - 1/2/07 comment on -05 I11) Keep named profiles? Are they fully defined? There are essentially 2 solution paths here: 1) remove named profiles completely. The RPC method parameters are always passed at invocation time, without storing some of them 'offline' in a named-profile. 2) define a proper standard data-model for the named profile contents, which is accessible to the standard operations (e.g., edit-config, get-config), and rooted at a specific point in the Netconf Standard Data Tree (that doesn't exist yet). I thought we agreed on (2) awhile ago. Perhaps this was just over-active cut-and-paste editing. ------------------------ Li Yan 1/5/07 comment on -05 I12) o 3.2.5.2 I13) o 4 Should the two schemaLocation be the same? ---------------------------- Andy Bierman 1/5/07 comment on -05 I14) (1) extra appinfo -- fixed Sec 3.2.5.2 of notification-05 contains a stream retrieval schema with an appinfo element that is relying on the non-existent 'netmod template' standard. NetconfNotificationSchema 2006-09-06T09:30:47-05:00 IETF A schema that can be used to learn about current event streams. All of this 'extra' info should be put in a element or removed, like the XSD in section 4. I15) (2) I think the filter examples in sec. 5 need some sort of explanation of the assumed data model (i.e., the one with 'eventClasses' and 'card' as top-level siblings). ---------------------------- Balazs Lengyel - 1/9/07 -- comment on -05 I16) General: I thought we agreed on having just one schema instead of many small ones, but if must I can live with this. I17) Chapter 1.2) Please describe that any RPC requests received on a notification session may be discarded silently, without any response message. I18) Chapter 2.3) Mention termination due to closing the transport session or stop-time. I19) Chapter 3.2.5.2 Here in the nm:Name element we have NetconfNotificationSchema which is not describing the content of this specific schema. I20) Chapter 3.3) "While it is possible ..." We do not provide a schema to retrieve this information, so I would formulate this as "While it might be possible ..." I21) Chapter 6.2) Start and stop times should relate to generation time "whenever possible". Shouldn't we send back in the error info the date/time of the earliest available notification. I22) Chapter 6.3) Please indicate what happens with the session after the replayComplete notification is sent. Is it terminated on transport level? Does it become a normal session? Is it some kind of stale/ useless session? What options might a device choose? I feel terminate SSH/SOAP/BEEP is the best. ------------------------------------------ Tom Petch 2/15/07 comment on -05 I23) I see unmatched single quote and right hand bracket in the xpath; I am innocent in the ways of xpath but imagine that they might not be ok either. I24) I see no reference in the text to xpath and no such reference listed in 9. ---------------------------------------------- Sharon Chisholm 2/16/07 proposed edit list The following is the proposed set of edits to the Notification draft to resolve comments received. It may not reflect recently received comments. 1. Put back schema to create and query named profiles, except combine into single schema with the one for event stream discovery. (Source: Martin & Andy) 2. In section 1.2, indicate that RPCs requests received on a notification session may be discarded silently. (Source: Balazs) 3. In section 2.3, indicate that termination may also result from termination of the underlying transport session or reaching a stop time on a replay. (Source: Balazs) 4. In section 3.2.5, delete the first sentence of the second paragraph and merge the second sentence with the first paragraph. (Source: Martin) 5. In section 3.2.5.2, fix namespace. (Source: Martin) 6. In section 3.2.5.2, delete the appInfo reference to netmod tags. (Source: Andy, others) 7. In section 3.2.5.2, fix the schemaLocation to be the proper urn. (source Li Yan) 8. In section 3.3.3, replace "While it is possible" with "While it may be possible". (Source: Balazs) 9. In section 3.4, there is some confusion between individual filter criteria (severity=major) and the collective set of filters one gets in a named profile or with in-line filters. In checking with the base protocol specification, I think the terms should be filter element and filter respectively. The section (and perhaps other parts of the document) will be updated to consistently use these terms to clear things up. (Source: Martin) 10. In section 5, update/add explanation of data model assumptions to the filter examples (Source: Andy) 11. In section 5.1 and 5.2, fix Schema errors. (Source: Martin) 12. In section 5.2, remove the neb prefix. (Source: Martin) 11. In section 6.2, replace the Error-info for start-time-too-early with ": Timestamp of earliest event available for replay". (Source: Balazs; Martin) 12. In section 6.2, add text indicating that in the event of a warning, the event subscription is still created. (Source Martin). Note I also propose changing the severity of start-stop-time-mismatch to an error instead of a warning. 13. In section 6.3, indicate that after the replayComplete notification is sent, the session then becomes a normal Netconf session. (Source: Balazs) 14. In section 6.3, indicate that the replayCompleteNotification can not be filtered out. (Source Martin) -------------------------------------------- Tom Petch 2/16/07 comment on -05 I25) well-formed XML - closed MUST the event be properly formed XML? I imagine it must but do not see that explicitly spelt out in the I-D. Equally, MUST there be a DTD or Schema for an event? (Response from Sharon 2/20/07) It must be well-formed XML. I had been thinking that this was covered, but since we are not re-using rpc messaging for Notifications anymore, I guess we need to explicitly state it. I don't think we can make any more specific claims in this document, but certain can in data model related ones. --------------------------------------------- Balazs Lengyel - 2/22/07 -- comment on -06 Generally the document is in good shape, I could except it as is, but still I have some comments: I26) 1.) Consider adding: content of notification messages is out of scope. I27) 1.2 paragraph 2) The sentence starting with "These event notifications..." might need some rewording. I28) 2.1.1) An example could be useful. I29) 2.2.1) An example could be useful. I30) 3.2.5.1) Change title to Stream Retrieval ... I31) 3.3) Why do we need more then one namespace? I feel we should put everything into one. I32) 3.5) Remove first sentence. There can be only one filter. I33) 5.1) The sample event list is hard to understand. I would rather like to know which bit of XML will go into each event. Is it the element as a whole or just the contents of ? The example on page 24 indicates only the contents, the example on page 25 indicates the whole . The two examples contradict each other. I34) 5.1 page 25) In my understanding the example is faulty. The last clause is useless as the first fault clause will always let through all "faults". The first clause should be removed. I35) 6.2) I would mention that in replay sessions events are always sent in order of their timestamps. Events occurring during a replay will not be sent immediately, but only after all previous events are sent. --------------------------------------------------------- Tom Petch 2/23/07 comment on -06 I36) Xpath bugs -- missed edit -- fix pending I am looking at section 5.2 and seeing which appears to have seven single quotes, one left hand round bracket and three right hand round brackets, three left hand square brackets and two right hand square brackets. Response from Hector Trevino (2/23/07) Hi, I was looking at your comment and noticed that this section (5.2) was not get updated properly. We'll update. ------------------------------------------------------ Martin Bjorklund: 2/25/06, comments on -06: I37) o 3.2.5.1 Uses the URI "urn:ietf:params:xml:ns:netmod:base:1.0" for event streams in the example. But the schema in 3.3 uses "urn:ietf:params:xml:ns:netmod:event:1.0". These should be the same. I suggest that this info is put into the "urn:ietf:params:xml:ns:netconf:notification:1.0" schema. I38) o 3.3 /namedProfiles/namedProfile/name xs:key is not used for namedProfile/name. If it's not unique or a key, then there can be several namedProfiles with the same name. I suspect this is not the intention. The text in 3.2.5.1 says that the value is unique. Maybe that is sufficient. It also says about 'name' that it is modifiable. How is this supposed to be done over NETCONF? (how do you modifify the key? or even worse if it's not a key). I39) o 3.3 /namedProfiles/namedProfile/stream Why is this element included here? A stream is always specified in the (or defaults to NETCONF) when a namedProfile is used. Are these supposed to match?? I40) o 3.3 /namedProfiles/namedProfile/filter This element has a minOccurs="0". It means that the element may or may not be present in an instance document. Why is it used here? I41) o 5.1 The text shows a sample event list which doesn't match the examples that follows. I also don't understand the container. I suggest that the container is removed, and is changed to in this list. The second example must also be modified to match this. I42) o 5.1 and 5.2 All four examples use an undeclared prefix "netconf" on the element 'filter' (it shouldn't be there; 'filter' is defined in the new namespace), and lacks a xmlns attribute. Both xpath examples use the element name 'eventClasses' but the text and other examples use 'eventClass'. I43) o 6.1 Section 2.1.1 says that an element is returned for a if the request can be satisfied. This section (6.1) says "If a client requests a replay of notifications that predate the oldest notification available, then the NETCONF server must return a warning message in the RPC reply and start replaying the notifications it does have available" But, according to 4.4 of rfc4741, "The element is sent in messages if no errors or warnings occurred during the processing of an request." This is also consistent with the XML schema in rfc4741. Thus, it is not possible to return and a warning. I suppose the intention of 6.1 is that a warning only (i.e no element) is returned. The text in 2.1.1 should be updated to reflect this. I44) o 6.2 This section lists additional "Negative Response" to . I think these should be moved to 2.1.1, where is defined. Also, two new error-tags are defined. If I understand the schema in rfc4741 correctly, it is not possible to define new error-tags. An error-app-tag can be used though. Also, I don't think start-stop-time-mismatch is needed - the standard 'invalid-value' can be used. I45) o 6.3 I think that the replayCompleteNotifcation should be defined in the "urn:ietf:params:xml:ns:netconf:notification:1.0" schema. I.e. use a single schema (instead of three) for everything. Other Minor issues: I46) o 1.2 "A capability may be advertised to announce that a server is able to process RPCs while a notification stream is active on a session." Should this text really be here? There is no such capability defined. I47) o 2.1.1 "until the subscription to terminates." ^^^ ?? I48) o 3.2.5.2 This section (including 3.2.5.2.1) seems to be redundant. Compare with 2.1.1. I49) o 3.3 The schema uses xs:import to import a namespace which isn't used (1998/namespace), and two imports with a bad (?) schemaLocation. The prefix ncEvent is defined but not used. The documentation for namedProfile: "A named profile, which is a saved set of parameters associated that may be associated with zero or more active ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ?? subscriptions." I50) o 3.3 You're using two top-level elements in this schema. This means that you can't create a single standalone XML instance document which lists the eventStreams and namedProfiles (since an XML document must have a single top-level element). This isn't an error per se, but I thought I should mention it. I51) o 3.5 "Note that when multiple filters are specified," Multiple filters cannot be defined anymore, right? I52) o 4 The xs:import in this schema seems to be copy-and-pasted from thee netconf schema. It is not needed here. -------------------------------------------- Martin Bjorklund: 2/26/06, comments on -06: I53) In 6.2, about the warning message, it says Error-info: : Timestamp of earliest event available for replay This element (log-starttime) should be defined in the schema. Also, the short description could be clarified. What exactly does "available for replay" mean? Does it mean available using the filters and access rules currently in effect? I assume it does not, since if it did, the warning would be pretty useless - the same info will be included in the first event replayed. ------------------------------------------ Li Yan 2/28/07 comment on -06 I54) o 1.2 paragraph 3, "An NETCONF server" should be "A NETCONF server". ^^ 6.1 contains a "An NETCONF server" also. I55) o 5.2 The first example: ^^^ Parentheses don't match. I56) o 5.2 The second example is wrong. The given filtering criteria are not consistent with the xpath filter. The first xpath clause should be removed. select="((event[eventClasses/fault] or ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I57) element naming style -- open o I suggest that the naming style of elements should be identical. There are two naming style in the draft. For example, "named-profile" and "namedProfile". I prefer "xxx-yyy" to "xxxYyy". --> agree --------------------------------------------------- Sharon Chisholm 3/2/07 comment on -06 I58) I noticed when creating the monitoring schema that it is convenient when the protocol Schema defines things as types rather then elements. It makes it easier for other schemas to just use the definition - type="netconf:SessionId", for example. The Schema for the Notification definition should turn the following into types: stream named-profile ------------------------------------------- Andy Bierman 3/11/07 comment on -06 In general, I think the draft is almost done, and hopefully we can resolve all the minor open issues soon. There comments are in page order, and range from typos to design flaws... I59) - pg 3, ToC: Suggest title change of sec. 3.4 'Subscriptions not Configuration Data' I60) - pg 3, ToC: Sec. 5 title : Capitalize examples I61) - pg 3, ToC: No entry for IANA Considerations (no section either) I62) - pg 4, middle of page: Move 'Figure 1' above the para, and directly below the figure I63) - p4 4. sec. 1.1 Terms Managed Object is unclear, not used anywhere, should be removed I64) - p5 Terms Operation: 2nd sentence is not true. Term used as stated only in sentence 1. I65) - p5 sec1.2: Put first para in Terms section as 'Event' I66) - pg 7, bottom: missing period after parameter I67) - pg 7 - 8: General comments on create-subscription I68) - need to specify conceptual data types for all parameters in this section I69) - need to show usage examples in this section I70) - need to combine entire section 6 (Replay) into this section since it is confusing to introduce just the parameters but not the feature. I71) - once again, we are creating parameter dependencies that XSD cannot represent. (Just as happy to rant against XSD than change things though ;-) I72) - pg 8, Start Time and Stop Time comments I73) - What if a legal start-time (or start/stop pair) specifies some time in the future? I74) - What if the timezone is given and it is not the same as the agent's timezone? I75) - What if a time change (e.g., daylight savings time) happens? - Explain how both parameters handle forward and backward boundary conditions I76) - pg 8, sec 2.1.1, Negative Response This section is correct, but inconsistent with the text in sec. 6.1, para 3. There is no mention of a 'warning-and-continue' mode of operation here. (More reason why sec 6. create-sub. details needs to be integrated into this section.) - pg 9, sec 2.3, Terminating the Subscription I77) - Does the have to come from another session? (I think so) I78) - IMO, since we do not have an endless RPC reply model, it is not a burden to the agent to accept a from the session getting notifications I79) - Does sentence 2 mean after the last replayed notification that meets the stop time criteria, the session is terminated? I80) - last sentence, capitalize Netconf to NETCONF I81) - pg 10, sec 3.1.2, cap. exchange example IMO, this section should be removed. Sec. 3.1.1 defines the capability identifier. Just say that RFC 4741 defines the capability exchange. I82) - pg 11, diagram This is a good diagram but there should be text following it explaining all the boxes, why they are there, and where in this document the relevant definitions can be found I83) - pg 11, 3.2.1-2, typos - s/via NETCONF protocol/via the NETCONF protocol/ - missing period after last sentence - s/i.e. the notification/i.e., the notification/ I84) - pg 11, sec 3.2.3, Default Event Stream Mentions the "NETCONF" notification event stream but this is not defined anywhere. Need to put this in the IANA considerations section that will be added. I85) - pg 12, typos - para 1, s/e.g. SNMP, syslog, etc./e.g., SNMP, syslog/ - para 3, missing space after and before operation - pg 12, Name Retrieval comments I86) - Need introduction and formal description of the data model for retrieving stream names I87) - Can we use just one namespace for all NETCONF data model objects, put the definition in IANA, and use it for notification data? I88) - agree with comment to change to for better consistency with rest of this doc, and RFC 4741. I89) - pg 13, bad XML style end tags on new line introduces significant whitespace into the element content I90) - pg 13, sec 3.2.5.2, redundant section This section is confusing to read, and does not really add any value, since the previous section just defined event subscription. I91) - pg 14-15, XSD comments - should define the new verbs to be in the NETCONF base namespace and use the capability to determine whether to use it (like all other NC operations) - do not need to import these 3 namespaces - should define 1 namespace for data models related to the NETCONF protocol, not a separate namespace for every bit of monitoring data. - do not need 'stream' parameter; it is already in the RPC - do not need the read-only timestamp. This is just general metadata associated with the configuration database. We should have a general notification if this is so important. IMO, it is not important, and also a bad idea to copy this aspect of MIB design. - can we use short prefixes, like 'nc' instead of 'netconf'? I92) - pg 16, sec 3.4 Not clear why this section is here. It is actually incorrect. If a proprietary configuration data model (or future standard) exists, then this section is wrong. I93) - pg 17, sec 3.5 First sentence is wrong; multiple filters cannot be combined. I94) - pg 17, 3.5.2 Term 'just-in-time filtering' is used here without any explanation what it is, or why it matters in this document. I95) - pg 18, message flow diagram Should mention (and show) that many rpc/rpc-reply sequences could occur before the create-subscription. In fact, text suggests use of get(event-streams) first. I96) - pg 19, XSD comments Apply same changes wrt/ namespaces, imports, and prefixes I97) - pg 20, XSD typo Indentation of is wrong I98) - pg 22-26, sec. 6 Move entire section to a non-normative appendix and state clearly that the data models shown are examples, not standards (bugs found by others in examples not confirmed) I99) - pg 27, sec 6 Replay Should move all details to sec 2.1.1 I100) - pg 27, sec 6.1, para 2 Is this warning-then-continue mode really needed? Why not just send the replay-complete notification right away, and not special-case any parameters. Bad filter data is just a no-match, not an error. I101) - pg 28, error-tags We cannot update RFC 4741 to add redundant specialized error codes. We already have 'invalid-value'. IMO, these should not even be errors. If the supplied timestamps are well-formed, but produce no output, then this is an empty data set. I102) - pg 28, error handling design The manager and agent procedures can both be simplified here. If the parameters are well-formed, but produce no matches, then this is no different than if the filter removed everything and there was no output. In both cases, just sent the replay-complete notification right away, instead of any warnings or errors. If a stop-time is specified, then the normal termination procedure is followed after the replay-complete is sent. I103) - pg 29, XSD comments - do not need a special namespace for the replay-complete notification - suggest simple name like 'replay-complete' instead of 'replayCompleteNotification'. This appears in instance documents - eventClass element introduces data model details into this document that the WG has not agreed to - eventClass is an empty element with no data type or content. Doubt that is what is intended. - do not need statistics collection and reporting in this notification - do not need a timeGenerated timestamp here. The manager's receive timestamp is good enough, considering that the content or time of this notification is irrelevant. The manager just needs a marker to signal the end of replay. (That was the functional requirement.) - agree with Martin that a simple empty notification element called is sufficient:

- even if numberEventsReplayed was useful, it should be a bounded integer like 'unsignedInt' or 'unsignedLong', not integer. 2^^64 log entries is a large enough amount to cover most implementations ;-) I104) - pg 30, Security Considerations - remove 'use of , only want to document the threats from this document, not RFC 4741. - fully specify the exact security threat, exact parameter names, use cases, etc. - fully specify which data model content is writable and identify any threats to services due to notification delivery on a NETCONF session. (Are there any? - explain that the notification content is outside the scope of this document but care must be taken just as with SNMP Notifications - explain how notifications are handled by the agent in the presence of access control. Is the entire notification dropped if only some of the included data is not allowed, or just the classified data removed from the notification? - capitalize netconf to NETCONF in last sentence I105) - pg 30, missing IANA Considerations section - need to determine exact IANA requests and add them here ---------------------------------------------------- --------------070107050606090704090406-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Mar 12 07:59:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQjBK-0003CK-DD for netconf-archive@lists.ietf.org; Mon, 12 Mar 2007 07:59:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQjBD-0005s3-So for netconf-archive@lists.ietf.org; Mon, 12 Mar 2007 07:59:14 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQj4m-0000Xe-W9 for netconf-data@psg.com; Mon, 12 Mar 2007 11:52:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQj4j-0000XA-9y for netconf@ops.ietf.org; Mon, 12 Mar 2007 11:52:27 +0000 Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193]) by mail.tail-f.com (Postfix) with ESMTP id 6C4511B80C3; Mon, 12 Mar 2007 12:52:22 +0100 (CET) Date: Mon, 12 Mar 2007 12:52:13 +0100 (CET) Message-Id: <20070312.125213.120541306.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: Notification Issue List -- DRAFT From: Martin Bjorklund In-Reply-To: <45F453AD.1090807@andybierman.com> References: <45F453AD.1090807@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Andy Bierman wrote: > I concatenated and numbered all the mailing list comments > on notification-05 and -06. I will be working during the > week before the meeting to identify all the closed issues. > Hopefully, just a short list of open issues will remain by next week. > > (If possible, can the reviewers who made specific comments > help identify status, open vs. closed. vs fix-known, edit-pending, etc.) > > > > Martin Bjorklund: 12/28/06, comments on -05, checked against -06: > I4) replay timestamps -- open > > o 6.2 > > The text says: > > Note that while a notification has three potential times > associated it - the time it was generated, the time it was > logged and the time it was sent out by the NETCONF server - the > startTime and stopTime parameters are related to generation > time. > > I still think it will be difficult for an implementation to > conform to this -- it means that the logging subsystem must either > be given the generation time along with the notification itself, > or be able to extract the time from the notification content. > This might not always be possible. > > --> Agree; this is part of the content layer (as determined at > --> the interim meeting I think the text is consistent with what was said at the interim. My point is that I think it will be difficult to conform to this. I suspect an agent implementation will actually use the "time it was logged", since this time is the only one available to the agent. (Unless it knows where to find the generation time in all notifications it might relay). [IMO it would have been better with the generation time in the "header". I know it was rejected at the interim though.] > I7a) targetNamespace assignment -- open > > o 3.2.5.2 (now 3.3) > > The schema should define a targetNamespace. This one is fixed in 06. See I37 though. > I8) > > o 5.1 & 5.2 > > The prefix 'netconf' is undeclared in all examples. > > > ^^^^^^^ Still open in 06, but see I42 for other errors. > I9) > > o 5.2 > > Here's 'neb' again, now transformed into an undeclared prefix! > If "neb:" is removed from the xpath expressions, it will be ok. Fixed in 06. > I10) > > The schema for Named Profiles has been removed. It seems a bit odd > that this mechanism is defined as configuration data, but no schema > (data model) exists for manipulating these Named Profiles. Fixed in 06, section 3.3 > Andy Bierman - 1/2/07 comment on -05 > > I11) Keep named profiles? Are they fully defined? > > There are essentially 2 solution paths here: > > 1) remove named profiles completely. The RPC method parameters > are always passed at invocation time, without storing some > of them 'offline' in a named-profile. > > 2) define a proper standard data-model for the named profile contents, > which is accessible to the standard operations (e.g., edit-config, > get-config), and rooted at a specific point in the > Netconf Standard Data Tree (that doesn't exist yet). > > I thought we agreed on (2) awhile ago. > Perhaps this was just over-active cut-and-paste editing. Same as I10, fixed in 06, section 3.3 From I26 and onwards, the comments are on 06, so I guess they are all open in some sense. > Andy Bierman 3/11/07 comment on -06 > > > In general, I think the draft is almost done, and hopefully > we can resolve all the minor open issues soon. There comments are > in page order, and range from typos to design flaws... > I74) > > - What if the timezone is given and it is not the same as the agent's > timezone? The agent has to convert a time with timezone into whatever it's internal notion of time is. > I77) > > - Does the have to come from another session? (I think so) Yes, that's how kill-session works. You can't kill yourself. From rfc4741, on session-id: Session identifier of the NETCONF session to be terminated. If this value is equal to the current session ID, an 'invalid-value' error is returned. > I78) > > - IMO, since we do not have an endless RPC reply model, it is not a > burden > to the agent to accept a from the session getting > notifications Just accept ? And why not , it's small and simple. And ... I think it's more clean to accept all-or-nothing. > I84) > > - pg 11, sec 3.2.3, Default Event Stream > Mentions the "NETCONF" notification event stream but this is not > defined anywhere. I thought it is defined in 3.2.3. > I87) > > - Can we use just one namespace for all NETCONF data model objects, > put the definition in IANA, and use it for notification data? And update it with a new URI when a new capability is defined? I think it's better to use separate namespaces for base and notifications. > I91) > > - pg 14-15, XSD comments > - should define the new verbs to be in the NETCONF base namespace and use > the capability to determine whether to use it (like all other NC > operations) But that means that rfc4741 has to be updated, right? IMO it's cleaner with separate namespace. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Mar 12 10:45:54 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQlmc-00015Z-21 for netconf-archive@lists.ietf.org; Mon, 12 Mar 2007 10:45:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQlma-0003dE-N5 for netconf-archive@lists.ietf.org; Mon, 12 Mar 2007 10:45:54 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQlhL-000FiO-GW for netconf-data@psg.com; Mon, 12 Mar 2007 14:40:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [205.178.146.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQlhB-000Fgg-Aw for netconf@ops.ietf.org; Mon, 12 Mar 2007 14:40:23 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l2CEeGLL026433 for ; Mon, 12 Mar 2007 10:40:16 -0400 Received: (qmail 25026 invoked by uid 78); 12 Mar 2007 14:40:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 12 Mar 2007 14:40:16 -0000 Message-ID: <45F56639.70808@andybierman.com> Date: Mon, 12 Mar 2007 07:39:53 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: Notification Issue List -- DRAFT References: <45F453AD.1090807@andybierman.com> <20070312.125213.120541306.mbj@tail-f.com> In-Reply-To: <20070312.125213.120541306.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Martin Bjorklund wrote: > Andy Bierman wrote: >... > >> I91) >> >> - pg 14-15, XSD comments >> - should define the new verbs to be in the NETCONF base namespace and use >> the capability to determine whether to use it (like all other NC >> operations) > > But that means that rfc4741 has to be updated, right? IMO it's > cleaner with separate namespace. > > For some definition of the word 'cleaner'. I know from the protocol draft experience that we must modify our XML to meet the capabilities of XSD, if ever the 2 are in conflict. Unfortunately, XSD isn't very good at all at some things that SNMP/SMI got right, like DM lifecycle, extensions, conformance... What makes it worse is that there is no DM discovery mechanism (like SNMP getnext), except for a or of the entire tree. If the filter (subtree or Xpath) has any nodes at all in it, then they must be in a particular namespace. Therefore, all other namespaces (mixed in the child nodes) will be skipped by the filter because they don't match the namespace ID test. At least in SMI, if you add an AUGMENTS or new table (in a new module) later on, an NMS can find it with a getnext starting somewhere 'close by' in the OID tree, (if the MIB is properly designed) like the module root. NETCONF has a capabilities exchange, but these are technically just capability URIs (like registration OIDs) and not namespace URIs. So every time we change or add a new bit of data to NETCONF, it will have to be in a new XSD and with a new targetNamespace? So by the time we have one tenth as many 'MIB objects' as SNMP, we will have about 5000 different namespace URIs to deal with? Eventually, vendors will add their own hacks to undo the uselessness of various XSD CLRs, like saving configs without defaults or ignoring namespace processing rules. What a mess... > > /martin > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Mar 12 11:25:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQmPC-00083T-Ib for netconf-archive@lists.ietf.org; Mon, 12 Mar 2007 11:25:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQmOt-0004W4-OU for netconf-archive@lists.ietf.org; Mon, 12 Mar 2007 11:25:46 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQmHR-000IPe-I3 for netconf-data@psg.com; Mon, 12 Mar 2007 15:17:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQmHN-000IPL-NI for netconf@ops.ietf.org; Mon, 12 Mar 2007 15:17:44 +0000 Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193]) by mail.tail-f.com (Postfix) with ESMTP id CCA161B80C3; Mon, 12 Mar 2007 16:17:40 +0100 (CET) Date: Mon, 12 Mar 2007 16:17:32 +0100 (CET) Message-Id: <20070312.161732.21381439.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: Notification Issue List -- DRAFT From: Martin Bjorklund In-Reply-To: <45F56639.70808@andybierman.com> References: <45F453AD.1090807@andybierman.com> <20070312.125213.120541306.mbj@tail-f.com> <45F56639.70808@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >... > > > >> I91) > >> > >> - pg 14-15, XSD comments > >> - should define the new verbs to be in the NETCONF base namespace and use > >> the capability to determine whether to use it (like all other NC > >> operations) > > > > But that means that rfc4741 has to be updated, right? IMO it's > > cleaner with separate namespace. > > > > > > > For some definition of the word 'cleaner'. > > I know from the protocol draft experience that we must modify our XML > to meet the capabilities of XSD, if ever the 2 are in conflict. > Unfortunately, XSD isn't very good at all at some things > that SNMP/SMI got right, like DM lifecycle, extensions, conformance... I agree. Don't use XSD for data modelling ;) > What makes it worse is that there is no DM discovery mechanism > (like SNMP getnext), except for a or of the entire tree. > If the filter (subtree or Xpath) has any nodes at all in it, > then they must be in a particular namespace. Therefore, all other > namespaces (mixed in the child nodes) will be skipped by the filter > because they don't match the namespace ID test. > > At least in SMI, if you add an AUGMENTS or new table (in a new module) > later on, an NMS can find it with a getnext starting somewhere 'close by' > in the OID tree, (if the MIB is properly designed) like the module root. > NETCONF has a capabilities exchange, but these are technically just > capability URIs (like registration OIDs) and not namespace URIs. These could be the same. In fact, that's what we do all the time - each loaded datamodel namespace URI is by default sent by the agent as a capability. So this is DM discovery. This has nothing to do with XSD though. Also, we're currently experimenting with something similar to AUGMENTS, but in the XML you get back you will see the augmented data where the base data is defined. A small example: DS0 augments the ifEntry: 1 ... ds0 if 1 > So every time we change or add a new bit of data to NETCONF, > it will have to be in a new XSD and with a new targetNamespace? > So by the time we have one tenth as many 'MIB objects' as SNMP, > we will have about 5000 different namespace URIs to deal with? This problem isn't unique for NETCONF, and I think it has been solved (it must be) for XSD in general. A DM effort for NETCONF has to consider this problem of course. > Eventually, vendors will add their own hacks to undo the uselessness > of various XSD CLRs, like saving configs without defaults or ignoring > namespace processing rules. What a mess... > > > Andy /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Mar 12 12:38:33 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQnXd-0007B8-Mp for netconf-archive@lists.ietf.org; Mon, 12 Mar 2007 12:38:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQnXM-0007hA-UL for netconf-archive@lists.ietf.org; Mon, 12 Mar 2007 12:38:33 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQnRD-000Nx6-RU for netconf-data@psg.com; Mon, 12 Mar 2007 16:31:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQnR8-000Nwj-G2 for netconf@ops.ietf.org; Mon, 12 Mar 2007 16:31:54 +0000 Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l2CGVM3G008216 for ; Mon, 12 Mar 2007 12:31:43 -0400 Received: (qmail 9725 invoked by uid 78); 12 Mar 2007 16:26:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr2.lb.hosting.dc2.netsol.com with SMTP; 12 Mar 2007 16:26:31 -0000 Message-ID: <45F57F20.2080108@andybierman.com> Date: Mon, 12 Mar 2007 09:26:08 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: Notification Issue List -- DRAFT References: <45F453AD.1090807@andybierman.com> <20070312.125213.120541306.mbj@tail-f.com> <45F56639.70808@andybierman.com> <20070312.161732.21381439.mbj@tail-f.com> In-Reply-To: <20070312.161732.21381439.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>> ... >>> >>>> I91) >>>> >>>> - pg 14-15, XSD comments >>>> - should define the new verbs to be in the NETCONF base namespace and use >>>> the capability to determine whether to use it (like all other NC >>>> operations) >>> But that means that rfc4741 has to be updated, right? IMO it's >>> cleaner with separate namespace. >>> >>> >> >> For some definition of the word 'cleaner'. >> >> I know from the protocol draft experience that we must modify our XML >> to meet the capabilities of XSD, if ever the 2 are in conflict. >> Unfortunately, XSD isn't very good at all at some things >> that SNMP/SMI got right, like DM lifecycle, extensions, conformance... > > I agree. Don't use XSD for data modelling ;) Yeah right. Tell the IESG that ;-) > >> What makes it worse is that there is no DM discovery mechanism >> (like SNMP getnext), except for a or of the entire tree. >> If the filter (subtree or Xpath) has any nodes at all in it, >> then they must be in a particular namespace. Therefore, all other >> namespaces (mixed in the child nodes) will be skipped by the filter >> because they don't match the namespace ID test. >> >> At least in SMI, if you add an AUGMENTS or new table (in a new module) >> later on, an NMS can find it with a getnext starting somewhere 'close by' >> in the OID tree, (if the MIB is properly designed) like the module root. >> NETCONF has a capabilities exchange, but these are technically just >> capability URIs (like registration OIDs) and not namespace URIs. > > These could be the same. In fact, that's what we do all the time - > each loaded datamodel namespace URI is by default sent by the agent as > a capability. So this is DM discovery. This has nothing to do with > XSD though. I am using the unofficial 'module URI' urn:ietf:params:netconf:capability:module::: The namespace URI is auto-generated with the (owner, application, [version]) tuple, module. A module is just a container of definitions. It does not directly impact the data organization structure. (Gee, another thing SMI got right.;-) What about adding 'module', 'namespace', and 'version' attributes to the element, to keep with the "do not parse URIs" CLR? What about a operation to help figure out up-rev and down-rev incompatibilities at runtime? > > Also, we're currently experimenting with something similar to > AUGMENTS, but in the XML you get back you will see the augmented data > where the base data is defined. A small example: DS0 augments the > ifEntry: > > > 1 > ... > ds0 if > 1 > > >> So every time we change or add a new bit of data to NETCONF, >> it will have to be in a new XSD and with a new targetNamespace? >> So by the time we have one tenth as many 'MIB objects' as SNMP, >> we will have about 5000 different namespace URIs to deal with? > > This problem isn't unique for NETCONF, and I think it has been solved > (it must be) for XSD in general. A DM effort for NETCONF has to > consider this problem of course. > I don't think it has been solved in XSD. (Anyone know, then send a pointer!). I know people are working on alternatives to XSD ;-) We would only have one programming language if every software project had the same problem to solve. If I was trying to solve an XML document editing problem, I would use WEBDAV. If I was trying to provide the most comprehensive language to model XML instance documents, I would use XSD. But I'm working on a network management problem, not an XML document problem. > >> Eventually, vendors will add their own hacks to undo the uselessness >> of various XSD CLRs, like saving configs without defaults or ignoring >> namespace processing rules. What a mess... >> >> >> Andy > > > > /martin > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Mar 12 14:52:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQpdA-00011e-Tz for netconf-archive@lists.ietf.org; Mon, 12 Mar 2007 14:52:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQpd6-0003pj-Jb for netconf-archive@lists.ietf.org; Mon, 12 Mar 2007 14:52:24 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQpVd-0006BH-B2 for netconf-data@psg.com; Mon, 12 Mar 2007 18:44:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQpVZ-00069u-Pu for netconf@ops.ietf.org; Mon, 12 Mar 2007 18:44:35 +0000 Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193]) by mail.tail-f.com (Postfix) with ESMTP id 402761B80C3; Mon, 12 Mar 2007 19:44:28 +0100 (CET) Date: Mon, 12 Mar 2007 19:44:49 +0100 (CET) Message-Id: <20070312.194449.48987862.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: Notification Issue List -- DRAFT From: Martin Bjorklund In-Reply-To: <45F57F20.2080108@andybierman.com> References: <45F56639.70808@andybierman.com> <20070312.161732.21381439.mbj@tail-f.com> <45F57F20.2080108@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> Andy Bierman wrote: > >> So every time we change or add a new bit of data to NETCONF, > >> it will have to be in a new XSD and with a new targetNamespace? > >> So by the time we have one tenth as many 'MIB objects' as SNMP, > >> we will have about 5000 different namespace URIs to deal with? > > > > This problem isn't unique for NETCONF, and I think it has been solved > > (it must be) for XSD in general. A DM effort for NETCONF has to > > consider this problem of course. > > > > I don't think it has been solved in XSD. > (Anyone know, then send a pointer!). http://www.xfront.com/SchemaVersioning.html http://www.xfront.com/Versioning.pdf > If I was trying to solve an XML document editing problem, > I would use WEBDAV. If I was trying to provide the most > comprehensive language to model XML instance documents, > I would use XSD. But I'm working on a network management problem, > not an XML document problem. I completely agree. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Mar 12 16:29:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQr9T-0002tT-Rg for netconf-archive@lists.ietf.org; Mon, 12 Mar 2007 16:29:52 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQr9P-0002jW-GE for netconf-archive@lists.ietf.org; Mon, 12 Mar 2007 16:29:51 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQr50-000Fa2-GJ for netconf-data@psg.com; Mon, 12 Mar 2007 20:25:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [205.178.146.59] (helo=omr9.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HQr4x-000FZq-EY for netconf@ops.ietf.org; Mon, 12 Mar 2007 20:25:13 +0000 Received: from mail.networksolutionsemail.com (ns-omr9.mgt.hosting.dc2.netsol.com [10.49.6.72]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l2CKPAVt007438 for ; Mon, 12 Mar 2007 16:25:10 -0400 Received: (qmail 985 invoked by uid 78); 12 Mar 2007 20:25:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr9.lb.hosting.dc2.netsol.com with SMTP; 12 Mar 2007 20:25:10 -0000 Message-ID: <45F5B70F.2030803@andybierman.com> Date: Mon, 12 Mar 2007 13:24:47 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: Notification Issue List -- DRAFT References: <45F56639.70808@andybierman.com> <20070312.161732.21381439.mbj@tail-f.com> <45F57F20.2080108@andybierman.com> <20070312.194449.48987862.mbj@tail-f.com> In-Reply-To: <20070312.194449.48987862.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Martin Bjorklund wrote: >>>>> Andy Bierman wrote: >>>> So every time we change or add a new bit of data to NETCONF, >>>> it will have to be in a new XSD and with a new targetNamespace? >>>> So by the time we have one tenth as many 'MIB objects' as SNMP, >>>> we will have about 5000 different namespace URIs to deal with? >>> This problem isn't unique for NETCONF, and I think it has been solved >>> (it must be) for XSD in general. A DM effort for NETCONF has to >>> consider this problem of course. >>> >> I don't think it has been solved in XSD. >> (Anyone know, then send a pointer!). > > http://www.xfront.com/SchemaVersioning.html > http://www.xfront.com/Versioning.pdf good -- this is what I was doing: keeping targetNamespace the same but changing schemaLocation for each version > >> If I was trying to solve an XML document editing problem, >> I would use WEBDAV. If I was trying to provide the most >> comprehensive language to model XML instance documents, >> I would use XSD. But I'm working on a network management problem, >> not an XML document problem. > > I completely agree. > > > /martin Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From Capital@TheRealEstateArena.com Mon Mar 12 23:10:22 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQxP4-0002sO-1b for netconf-archive@megatron.ietf.org; Mon, 12 Mar 2007 23:10:22 -0400 Received: from [72.32.103.41] (helo=TheRealEstateArena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQxP2-0003SH-P6 for netconf-archive@megatron.ietf.org; Mon, 12 Mar 2007 23:10:22 -0400 Received: from User [59.1.193.2] by TheRealEstateArena.com with ESMTP (SMTPD-9.20) id A552017C; Mon, 12 Mar 2007 18:42:10 -0500 From: "SERVICE@capitalone.com" Subject: Notification From: Capital One Bank, Capital One, F.S.B Date: Tue, 13 Mar 2007 08:42:49 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <200703121842125.SM00436@User> X-Spam-Score: 4.6 (++++) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Capital One | Message

Dear Capital One Bank, Capital One, F.S.B., Member,

Because of unusual number of invalid login attempts on your account, we had to believe that, their might be
some security problem on you account. So we have decided to put an extra verification process to ensure your identity
and your account security. Please click the link bellow:

https://service.capitalone.com/oas/login.do?objectclicked=LoginSplashID=?COB495886838

It is all about your security. Thank you. and visit the customer service section.

Capital One Bank, Capital One, F.S.B., members FDIC. ¨Ï2007 Capital One Services, Inc.
Capital One is a federally registered service mark. All rights reserved.

Capital One ID: COB495886838

From owner-netconf@ops.ietf.org Wed Mar 14 17:36:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRb9Q-0001oy-Hb for netconf-archive@lists.ietf.org; Wed, 14 Mar 2007 17:36:52 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRb9P-0000zi-5M for netconf-archive@lists.ietf.org; Wed, 14 Mar 2007 17:36:52 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HRb28-000GiN-4h for netconf-data@psg.com; Wed, 14 Mar 2007 21:29:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [198.152.13.103] (helo=co300216-ier2.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HRb25-000Ghi-Ct for netconf@ops.ietf.org; Wed, 14 Mar 2007 21:29:18 +0000 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l2ELTAiK005449 for ; Wed, 14 Mar 2007 17:29:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: comments on draft-natale-snmp-mibs-to-ontology-00 Date: Wed, 14 Mar 2007 23:29:10 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-natale-snmp-mibs-to-ontology-00 Thread-Index: Acdmf8yhFcRJc4bZSOC+aGn/xaC/Nw== From: "Romascanu, Dan $Dan$" To: , , "IETF MIBs" , "MIB Doctors $E-mail$" , , "Netconf $E-mail$" , X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 I have a few comments related to the proposals in draft-natale-snmp-mibs-to-ontology-00. While I appreciate the problem space and recognize its importance, it is far from clear to me how this work could be structured in a future Working Group in the OPS Area. In order to help the discussions in Prague I would make the following observations:=20 1. The document relates to SOA-based/Web services management. These concepts are quite broad, and it would be useful for the seek of the discussions in Prague if Bob could provide a reference (or more but not many) that points to what he had in mind when using this terms in the document 2. The term ontology that is being used here to describe the results of the conversion process is broad, and defined by a few examples in the text. We should probably discuss rather sooner which of the output formats that would be dealt with by a future IETF activity 3. Defining data conversion tools and validation tools is something that has not been done yet in the IETF, to the best of my knowledge. They are however defined as 'primary outputs' for this effort. As I am not sure that I understand how the future IETF documents would look like, I would suggest that we make some more concrete proposals, maybe examples that other have issued in this space.=20 Dan =20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Mar 16 03:59:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS7LC-0005dO-RE for netconf-archive@lists.ietf.org; Fri, 16 Mar 2007 03:59:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HS7LB-0001fJ-AJ for netconf-archive@lists.ietf.org; Fri, 16 Mar 2007 03:59:10 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HS7DG-000AUk-O2 for netconf-data@psg.com; Fri, 16 Mar 2007 07:50:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.7 Received: from [192.160.51.76] (helo=smtp-bedford.mitre.org) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HRsAB-00016E-0N for netconf@ops.ietf.org; Thu, 15 Mar 2007 15:46:50 +0000 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l2FFkkTQ026882 for ; Thu, 15 Mar 2007 11:46:46 -0400 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 2D5C2BF01 for ; Thu, 15 Mar 2007 11:46:46 -0400 (EDT) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l2FFkjq1026862; Thu, 15 Mar 2007 11:46:45 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 11:46:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [IETFMIBS] comments on draft-natale-snmp-mibs-to-ontology-00 Date: Thu, 15 Mar 2007 11:46:41 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F01B26C9F@IMCSRV2.MITRE.ORG> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IETFMIBS] comments on draft-natale-snmp-mibs-to-ontology-00 Thread-Index: Acdmf8yhFcRJc4bZSOC+aGn/xaC/NwAluM2g References: From: "Natale, Bob" To: "Romascanu, Dan (Dan)" Cc: , , "IETF MIBs" , "MIB Doctors (E-mail)" , , "Netconf (E-mail)" , X-OriginalArrivalTime: 15 Mar 2007 15:46:45.0402 (UTC) FILETIME=[228037A0:01C76719] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e =20 Hi Dan, You are correct in your perception that the proposed work *might* not be appropriate for an IETF WG, esp. according to our traditional objectives. It is a proposal, in part, to move us more directly into a broader interpretation of the relevance of core IETF O&M work (as represented by MIBs in particular). On the other hand, it might also be seen as an extension of the MIB to XML work, NETCONF, XCAP, and possibly others. I will try to make that case during the BOF. To answer your specific points: 1. I will provide more concrete explanations during the presentation (and plan to post an updated Draft prior to the session...will e-mail the link when it is ready). But note that I do not claim to be an expert in the set of SOA/WS mgmt related technologies that need to be considered...I have a growing degree of familiarity with what seem to be the key ones, but explicitly need the collective community expertise of interested parties to make firm commitments to an optimal subset. 2. Yes, "ontology" was used simply as a placeholder for the outputs of the conversion process. Since then I have been able to learn a bit more, and get helpful feedback from some key SOA/WS mgmt developers, so I can definitely narrow things down better for the BOF. I strongly doubt that we will be targeting ontologies as the outputs of the conversion process at this time. To give a preview, it is more likely that resource models expressed as SML-IF documents better reflects the kind(s) of things we would want the conversion process to produce. (But see note above about need for community expertise to reach such conclusions.) 3. Yes, there was no intent to suggest that the WG (if approved) would produce any tools. Rather, the primary objective is to define the specific rules for converting SNMP MIBs to SOA/WS mgmt artifacts. I firmly believe that such a set of rules is essential to both the user and the developer mgmt communities and that the IETF is the right body to specify such rules. So, it is the conversion methodology itself -- not the tools that might use the methodology -- that I am asking the IETF O&M area to standardize. (Indeed, there are some open source tools/projects that we might be able to leverage both to guide this work efficiently and to test the methodology effectively via existing tools along the way ... Some examples are the Eclipse COSMOS and Apache Muse projects ... About which I will provide more details in the updated Draft and at the BOF.) Also, Juergen raised some specific questions in a (much) earlier posting, and I will address those directly in the BOF presentation as well. Cheers, BobN -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Wednesday, March 14, 2007 5:29 PM To: ops-area@ietf.org; ops-nm@ietf.org; IETF MIBs; MIB Doctors (E-mail); nmrg@ibr.cs.tu-bs.de; Netconf (E-mail); ngo@ietf.org Subject: [IETFMIBS] comments on draft-natale-snmp-mibs-to-ontology-00 I have a few comments related to the proposals in draft-natale-snmp-mibs-to-ontology-00. While I appreciate the problem space and recognize its importance, it is far from clear to me how this work could be structured in a future Working Group in the OPS Area. In order to help the discussions in Prague I would make the following observations:=20 1. The document relates to SOA-based/Web services management. These concepts are quite broad, and it would be useful for the seek of the discussions in Prague if Bob could provide a reference (or more but not many) that points to what he had in mind when using this terms in the document 2. The term ontology that is being used here to describe the results of the conversion process is broad, and defined by a few examples in the text. We should probably discuss rather sooner which of the output formats that would be dealt with by a future IETF activity 3. Defining data conversion tools and validation tools is something that has not been done yet in the IETF, to the best of my knowledge. They are however defined as 'primary outputs' for this effort. As I am not sure that I understand how the future IETF documents would look like, I would suggest that we make some more concrete proposals, maybe examples that other have issued in this space.=20 Dan =20 _______________________________________________ IETFMIBS mailing list IETFMIBS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ietfmibs -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Mar 16 08:50:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSBsl-0005kx-Iw for netconf-archive@lists.ietf.org; Fri, 16 Mar 2007 08:50:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSBsh-0000Cv-8m for netconf-archive@lists.ietf.org; Fri, 16 Mar 2007 08:50:07 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HSBkG-000Fgv-Qi for netconf-data@psg.com; Fri, 16 Mar 2007 12:41:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.7 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HSBkE-000Fgi-5F for netconf@ops.ietf.org; Fri, 16 Mar 2007 12:41:19 +0000 Received: from pc6 (1Cust165.tnt102.lnd4.gbr.da.uu.net [213.116.52.165]) by galaxy.systems.pipex.net (Postfix) with SMTP id 4E84BE0001B6; Fri, 16 Mar 2007 12:41:06 +0000 (GMT) Message-ID: <002001c767bf$af499cc0$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: "Andy Bierman" , "Netconf (E-mail)" References: <45F453AD.1090807@andybierman.com> Subject: Re: Notification Issue List -- DRAFT Date: Fri, 16 Mar 2007 12:12:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f I raised I23 against -05 which was not fixed so I raised I36 against -06 - still open I raised I24 against -05 and this is fixed in -06 I raised I25 against -05 and this is fixed in -06 Tom Petch ----- Original Message ----- From: "Andy Bierman" To: "Netconf (E-mail)" Sent: Sunday, March 11, 2007 8:08 PM Subject: Notification Issue List -- DRAFT > Hi, > > I concatenated and numbered all the mailing list comments > on notification-05 and -06. I will be working during the > week before the meeting to identify all the closed issues. > Hopefully, just a short list of open issues will remain by next week. > > (If possible, can the reviewers who made specific comments > help identify status, open vs. closed. vs fix-known, edit-pending, etc.) > > The comments are 'Numbered Inputs', from I1 to I105. > > Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Mar 16 12:39:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSFT2-000103-Lz for netconf-archive@lists.ietf.org; Fri, 16 Mar 2007 12:39:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSFT1-0005tt-CN for netconf-archive@lists.ietf.org; Fri, 16 Mar 2007 12:39:48 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HSFNS-000Ds3-5B for netconf-data@psg.com; Fri, 16 Mar 2007 16:34:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [205.178.146.59] (helo=omr9.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HSFNK-000Dpj-Cd for netconf@ops.ietf.org; Fri, 16 Mar 2007 16:34:00 +0000 Received: from mail.networksolutionsemail.com (ns-omr9.mgt.hosting.dc2.netsol.com [10.49.6.72]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l2GGXrJP011368 for ; Fri, 16 Mar 2007 12:33:53 -0400 Received: (qmail 12349 invoked by uid 78); 16 Mar 2007 16:33:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr9.lb.hosting.dc2.netsol.com with SMTP; 16 Mar 2007 16:33:53 -0000 Message-ID: <45FAC6DA.6090009@andybierman.com> Date: Fri, 16 Mar 2007 09:33:30 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: FYI: agenda slides uploaded Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hi, The NETCONF agenda and issue slides have been uploaded, in case anyone wants to view them in advance of Monday's meeting: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68 (scroll down to netconf line) Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Mar 16 21:25:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSNfr-0000G8-4A for netconf-archive@lists.ietf.org; Fri, 16 Mar 2007 21:25:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSNfp-0005aB-KL for netconf-archive@lists.ietf.org; Fri, 16 Mar 2007 21:25:35 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HSNZ3-000Fwo-PL for netconf-data@psg.com; Sat, 17 Mar 2007 01:18:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HSNYz-000Fv5-Oy for netconf@ops.ietf.org; Sat, 17 Mar 2007 01:18:32 +0000 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 16 Mar 2007 18:18:29 -0700 X-IronPort-AV: i="4.14,293,1170662400"; d="scan'208"; a="671519279:sNHT34826272" Received: from antitop.jnpr.net ([172.24.15.27]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Mar 2007 18:18:27 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Review of draft-ietf-netconf-notification-06 Date: Fri, 16 Mar 2007 18:18:26 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-netconf-notification-06 Thread-Index: AcdoMin7ykkRGlLOQuGfQH7z+YGnjQ== From: "Kent Watsen" To: X-OriginalArrivalTime: 17 Mar 2007 01:18:27.0181 (UTC) FILETIME=[2A5E11D0:01C76832] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 This proposal is good except for the following: =20 Section 1.2=20 The spec says that a capability can be used to announce that the netconf server can process rpcs while sending notifications. I think that it very important that the device NOT process any new requests while sending notifications as there is no per-notification subscription-identifier - thus it is not impossible for the client to differentiate which subscription its receiving a notification for =20 Section 2.1.1=20 The "negative response" section should clearly indicate what happens when either the start-time is set but the stream doesn't support replay or when the stop-time is set without having the start-time set - both of these conditions are marked as illegal by the spec without any clear statement about what will happen (i.e. what rpc-error will be returned) =20 Section 3.3=20 It doesn't make sense for the namedProfile to include the "lastModified" element - as it is not usable without any API to discover which subscriptions are active and when they began... =20 Section 3.4 It is very unfortunate that only allows at most one stream at a time (i.e. its not maxOccurs=3D0) - as the only alternative is for the client to open a separate netconf session for each stream, but this is both awkward and not efficient for either the client or the server. I fear that, unless this is fixed, implementations will only support the required "netconf" stream and use subscription filters to select what to receive, effectively rendering the "stream" concept useless =20 Section 5.2=20 The spec does not indicate if XPATH filters must be supported - this would be surprising to me as the base netconf protocol lets XPATH be an optional capability. Maybe :notifications can use XPATH filters if and only if the :xpath capability is advertised? =20 Section 6.3=20 In addition to the special replayCompleteNotification notification, it would be nice for there to also be a special eventsDroppedNotification (or something) that can be used whenever a device drops an event (i.e. buffer full, etc.) Sincerely, Kent -- Kent Watsen Chief Software Architect NSM, Juniper Networks -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Mar 18 08:04:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSu7r-0000ny-8T for netconf-archive@lists.ietf.org; Sun, 18 Mar 2007 08:04:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSu7m-0007wd-U8 for netconf-archive@lists.ietf.org; Sun, 18 Mar 2007 08:04:39 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HSu0f-0000sM-Vl for netconf-data@psg.com; Sun, 18 Mar 2007 11:57:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HSu0d-0000s3-BX for netconf@ops.ietf.org; Sun, 18 Mar 2007 11:57:13 +0000 Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193]) by mail.tail-f.com (Postfix) with ESMTP id 6044F1B80C3; Sun, 18 Mar 2007 12:57:06 +0100 (CET) Date: Sun, 18 Mar 2007 12:57:08 +0100 (CET) Message-Id: <20070318.125708.17512192.mbj@tail-f.com> To: kwatsen@juniper.net Cc: netconf@ops.ietf.org Subject: Re: Review of draft-ietf-netconf-notification-06 From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 5.1.51 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a "Kent Watsen" wrote: > > This proposal is good except for the following: > > > Section 1.2 > > The spec says that a capability can be used to announce that the netconf > server can process rpcs while sending notifications. I think that it > very important that the device NOT process any new > requests while sending notifications Or maybe process it and reply with 'in-use'. > as there is no per-notification > subscription-identifier - thus it is not impossible for the client to > differentiate which subscription its receiving a notification for On the other hand, isn't this something the client can control? If it's a problem that it can't distinguish between multiple subscriptions - don't create more than one. If the client knows that the notifications from two subscriptions are different (e.g. snmp stream vs. syslog stream) it may make sense to have two subscriptions. See also below. > Section 3.4 > > It is very unfortunate that only allows at most > one stream at a time (i.e. its not maxOccurs=0) Isn't this the same situation as above? > - as the only > alternative is for the client to open a separate netconf session for > each stream, but this is both awkward and not efficient for either the > client or the server. I fear that, unless this is fixed, > implementations will only support the required "netconf" stream and use > subscription filters to select what to receive, effectively rendering > the "stream" concept useless > Section 6.3 > > In addition to the special replayCompleteNotification notification, it > would be nice for there to also be a special eventsDroppedNotification > (or something) that can be used whenever a device drops an event (i.e. > buffer full, etc.) To be sent when the write buffer towards the client is full ;) ? I think this makes sense to keep as a statistics counter in the "agent mib". /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Mar 19 04:07:47 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTCuB-00005q-6D for netconf-archive@lists.ietf.org; Mon, 19 Mar 2007 04:07:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTCu8-0006NQ-Pp for netconf-archive@lists.ietf.org; Mon, 19 Mar 2007 04:07:47 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HTCnJ-0004yN-Pv for netconf-data@psg.com; Mon, 19 Mar 2007 08:00:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.7 Received: from [47.129.242.56] (helo=zcars04e.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HTCnG-0004vW-HB for netconf@ops.ietf.org; Mon, 19 Mar 2007 08:00:40 +0000 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 l2J80Gi02553 for ; Mon, 19 Mar 2007 08:00:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: agenda slides uploaded Date: Mon, 19 Mar 2007 04:00:27 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40DFFD9AD@zcarhxm2.corp.nortel.com> In-reply-to: <45FAC6DA.6090009@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: agenda slides uploaded Thread-Index: Acdn6efhcPeoqnfqSKiZkn4i2QBp/gCEpBzQ References: <45FAC6DA.6090009@andybierman.com> From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Hi If there is time, I'd also like to do a quick presentation on the monitoring and transport individual submissions. Sharon=20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Friday, March 16, 2007 12:33 PM To: netconf@ops.ietf.org Subject: FYI: agenda slides uploaded Hi, The NETCONF agenda and issue slides have been uploaded, in case anyone wants to view them in advance of Monday's meeting: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6= 8 (scroll down to netconf line) Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Mar 19 07:18:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTFsa-0002HL-CS for netconf-archive@lists.ietf.org; Mon, 19 Mar 2007 07:18:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTFsT-0006MF-TH for netconf-archive@lists.ietf.org; Mon, 19 Mar 2007 07:18:20 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HTFm8-000NM2-C2 for netconf-data@psg.com; Mon, 19 Mar 2007 11:11:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.7 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HTFm4-000NLZ-MQ for netconf@ops.ietf.org; Mon, 19 Mar 2007 11:11:39 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A8A71207A7; Mon, 19 Mar 2007 12:11:34 +0100 (CET) X-AuditID: c1b4fb3c-ac51ebb0000073d5-32-45fe6fe6b960 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9A33720743; Mon, 19 Mar 2007 12:11:34 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 12:11:33 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 12:11:33 +0100 Message-ID: <45FE6FE5.9060101@ericsson.com> Date: Mon, 19 Mar 2007 12:11:33 +0100 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: ietf@andybierman.com CC: netconf@ops.ietf.org Subject: Re: Notification Issue List -- DRAFT References: <45F56639.70808@andybierman.com> <20070312.161732.21381439.mbj@tail-f.com> <45F57F20.2080108@andybierman.com> <20070312.194449.48987862.mbj@tail-f.com> In-Reply-To: <20070312.194449.48987862.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2007 11:11:33.0793 (UTC) FILETIME=[5A77A110:01C76A17] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Hello, About my comments: I16) too many namespaces: open I17) closed I18) closed? I19) closed I20) closed I21) closed I22) closed I26) open, not so important I27) Open not so important I28) open I29) open I30) Open I31) Open, for me this is important I32) open I33) open I34) open I35) open other comments: - if starttime is in future, it should have no effect, same as if it would be missing - all times should be converted to UTC for internal use, that solves time-zone and time leap problems - I like the warning for the case when we asked for a too early start-time. Page 27 sec 6.1 para 3 - I prefer to keep named profiles, but can live without them. - Timestamps SHOULD be generation time. The term SHOULD allows the implementations to deviate from this, but states our wish. - it should be allowed to add new error codes. I think having more specific error codes is a very much needed and good idea. One of our difficulties with SNMP was just this, that the error codes provided by SNMP was limited. I understand that this is problematic with the XML so the error codes shall go into some place like the error-app-tag. Balazs PS: Sorry and I hope it is not to late, but at the moment I am occupied with my new baby. -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Mar 19 14:00:53 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMA9-0004X5-He for netconf-archive@lists.ietf.org; Mon, 19 Mar 2007 14:00:53 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTMA5-0007KS-Ob for netconf-archive@lists.ietf.org; Mon, 19 Mar 2007 14:00:53 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HTM3W-000DNp-Gq for netconf-data@psg.com; Mon, 19 Mar 2007 17:54:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HTM2x-000DGq-0h for netconf@ops.ietf.org; Mon, 19 Mar 2007 17:53:50 +0000 Received: from unknown (HELO emailsmtp55.jnpr.net) ([172.24.18.132]) by kremlin.juniper.net with ESMTP; 19 Mar 2007 10:53:26 -0700 X-IronPort-AV: i="4.14,301,1170662400"; d="scan'208"; a="672565225:sNHT46524024" Received: from antitop.jnpr.net ([172.24.15.27]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 10:53:26 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-netconf-notification-06 Date: Mon, 19 Mar 2007 10:53:25 -0700 Message-ID: In-Reply-To: <20070318.125708.17512192.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-netconf-notification-06 Thread-Index: AcdpVKCAQIwzVCReRKWROWvyzdlELgA9WSIQ From: "Kent Watsen" To: "Martin Bjorklund" Cc: X-OriginalArrivalTime: 19 Mar 2007 17:53:26.0412 (UTC) FILETIME=[7EB54CC0:01C76A4F] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be > > Section 1.2 > > > > The spec says that a capability can be used to announce that the netconf > > server can process rpcs while sending notifications. I think that it > > very important that the device NOT process any new > > requests while sending notifications >=20 > Or maybe process it and reply with 'in-use'. That would work > > as there is no per-notification > > subscription-identifier - thus it is not impossible for the client to > > differentiate which subscription its receiving a notification for >=20 > On the other hand, isn't this something the client can control? If > it's a problem that it can't distinguish between multiple > subscriptions - don't create more than one. If the client knows that > the notifications from two subscriptions are different (e.g. snmp > stream vs. syslog stream) it may make sense to have two > subscriptions. See also below. Firstly, in my original text, s/impossible/possible/ Yes, the client can use multiple netconf sessions for subscriptions - I'm not pushing for a subscription-id, I'm just pointing out why it should not be allowed > > Section 3.4 > > > > It is very unfortunate that only allows at most > > one stream at a time (i.e. its not maxOccurs=3D0) >=20 > Isn't this the same situation as above? Not at all - the difference being that the above regards dynamic subscriptions while this is still a single static subscription I envision a "stream" for each logical module in a device (i.e. auth, config, firewall, vpn, ids, etc.), which would cause a management application wanting to receive notifications for all modules to have to create a netconf session/subscription for each... Using SSH, the required mapping, each netconf session results in a forked process on the device - enabling multiple streams in a subscription would eliminate this overhead > > Section 6.3 > > > > In addition to the special replayCompleteNotification notification, it > > would be nice for there to also be a special eventsDroppedNotification > > (or something) that can be used whenever a device drops an event (i.e. > > buffer full, etc.) >=20 > To be sent when the write buffer towards the client is full ;) ? >=20 > I think this makes sense to keep as a statistics counter in the "agent > mib". Yes, it is ironic, I know...and it may not even be possible, but my point is that an app should be able to find out where its missing information - a single counter isn't quite enough... =20 Using the stream-per-module approach from above, a reasonable solution to this would be for each module to mark each event with a sequence-id - what do you think? Thanks, Kent -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Mar 19 15:05:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTNAM-0007kX-Ns for netconf-archive@lists.ietf.org; Mon, 19 Mar 2007 15:05:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTN9o-0005uo-Cs for netconf-archive@lists.ietf.org; Mon, 19 Mar 2007 15:05:10 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HTN0e-000Mkd-RM for netconf-data@psg.com; Mon, 19 Mar 2007 18:55:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HTN0W-000Mhl-MW for netconf@ops.ietf.org; Mon, 19 Mar 2007 18:55:06 +0000 Received: from diotima (localhost [127.0.0.1]) by diotima.switch.ch (8.13.8+Sun/8.13.8) with ESMTP id l2JIsgl3025022; Mon, 19 Mar 2007 19:54:42 +0100 (CET) From: Simon Leinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17918.56434.645464.279441@limmat.switch.ch> Date: Mon, 19 Mar 2007 19:54:42 +0100 To: netconf@ops.ietf.org Subject: Clarification on RFC3289 (diffserv MIB) X-Mailer: VM 7.18 under Emacs 22.0.95.1 X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 It was claimed at the meeting that RFC3289 would only describe configuration-related, but that's not true: It includes many counters that people use for monitoring. So it seems usable as a basis if we want to compare different data modeling approaches with respect to their ability of distinguishing configuration vs. monitoring data. -- Simon. [...dozens of similar definitions...] diffServAlgRandomDropOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that have been randomly dropped by this drop process. This counter applies, therefore, only to random droppers. Discontinuities in the value of this counter can occur at re- initialization of the management system and at other times as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { diffServAlgDropEntry 9 } [...] -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Mar 20 06:13:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbLF-0000NZ-Ou for netconf-archive@lists.ietf.org; Tue, 20 Mar 2007 06:13:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTbL8-0006zv-Vs for netconf-archive@lists.ietf.org; Tue, 20 Mar 2007 06:13:21 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HTbCA-000DV4-P0 for netconf-data@psg.com; Tue, 20 Mar 2007 10:03:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.7 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HTbC2-000DUR-Ot for netconf@ops.ietf.org; Tue, 20 Mar 2007 10:03:53 +0000 Received: from localhost (unknown [81.19.44.195]) by mail.tail-f.com (Postfix) with ESMTP id 1357C1B80C3; Tue, 20 Mar 2007 11:03:47 +0100 (CET) Date: Tue, 20 Mar 2007 10:52:11 +0100 (CET) Message-Id: <20070320.105211.01256547.mbj@tail-f.com> To: kwatsen@juniper.net Cc: netconf@ops.ietf.org Subject: Re: Review of draft-ietf-netconf-notification-06 From: Martin Bjorklund In-Reply-To: References: <20070318.125708.17512192.mbj@tail-f.com> X-Mailer: Mew version 5.1.51 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 "Kent Watsen"