From owner-netconf@ops.ietf.org Wed Nov 02 09:01:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXJAx-0001Ss-J1 for netconf-archive@megatron.ietf.org; Wed, 02 Nov 2005 09:01:16 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07581 for ; Wed, 2 Nov 2005 09:00:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXJ2U-0001kQ-MY for netconf-data@psg.com; Wed, 02 Nov 2005 13:52:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXJ2T-0001k1-EU for netconf@ops.ietf.org; Wed, 02 Nov 2005 13:52:29 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jA2DqOq27416 for ; Wed, 2 Nov 2005 08:52:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 'Phase 2' Editing Sessions in Vancouver Date: Wed, 2 Nov 2005 08:52:07 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405878915@zcarhxm2.corp.nortel.com> Thread-Topic: Netconf 'Phase 2' Editing Sessions in Vancouver Thread-Index: AcXU31ZeREYY9Pp7TSqaN6/SBb4HmAK1MrqA From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi Ok. Let's start with the following: 1) Netconf Event Monday Afternoon Session II Meet at the bulletin board 2) Framework for Netconf Content (and other data model issues) Tuesday Afternoon Session II Meet at the bulletin board Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Chisholm, Sharon [CAR:5K50:EXCH] Sent: Wednesday, October 19, 2005 3:00 PM To: netconf@ops.ietf.org Subject: Netconf 'Phase 2' Editing Sessions in Vancouver hi I'm currently scanning the Vancouver IETF schedule for promising slots to hold a number of offline editing sessions for the Netconf Event and Netconf Content internet drafts. I am thinking we could hold quite a few sessions. The documents can be seen under 'id exists' at =09 https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dsearch_list&= s earch_job_owner=3D0&search_group_acronym=3D&search_status_id=3D&search_cu= r_sta te=3D&sub_state_id=3D6&search_filename=3Dnetconf&search_rfcnumber=3D&sear= ch_area _acronym=3D&search_button=3DSEARCH Expect updates within the next week or so. I will also post them http://standards.nortel.com/netconf/docs/IETF%2064/ Potential Timeslots (other than evenings, lunches and cookie breaks) ------------------- 1) Monday morning 2) Monday Afternoon Session II 3) Tuesday Afternoon Session II & III 4) Wednesday morning 5) Thursday morning =09 Please let me know if you are interested and what your preferred times are, as well as which documents you are interested in discussing.=20 Note that this does not preclude people sending comments on the mailing lists. Netconf content feedback can be sent to the Netconf Model list http://standards.nortel.com/netconf/index.html Netconf Event comments can perhaps be sent to this list, or if Andy and Simon object then they instead can be sent to the above list. 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: -- 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 Wed Nov 02 12:34:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMVF-0000DW-C5 for netconf-archive@megatron.ietf.org; Wed, 02 Nov 2005 12:34:25 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23855 for ; Wed, 2 Nov 2005 12:34:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXMOo-000INh-3Z for netconf-data@psg.com; Wed, 02 Nov 2005 17:27:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [47.129.242.56] (helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXMOn-000INU-AU for netconf@ops.ietf.org; Wed, 02 Nov 2005 17:27:45 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id jA2HOsq06412 for ; Wed, 2 Nov 2005 12:24:54 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DFD2.BB1A91C1" Subject: xmlpatch BOF in Vancouver Date: Wed, 2 Nov 2005 12:27:29 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D06EFA3AD@zcarhxm0.corp.nortel.com> Thread-Topic: xmlpatch BOF in Vancouver Thread-Index: AcXf0rM6XgUGF/8CQ9+F7pjj0A3gHA== From: "Glenn Waters" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DFD2.BB1A91C1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Heads up to the management folk, this work look hauntingly similar in concept to the Netconf work. Link to the draft being discussed follows. =20 http://www.ietf.org/internet-drafts/draft-urpalainen-simple-xml-patch-op s-01.txt=20 =20 Regards, /gww=20 ------_=_NextPart_001_01C5DFD2.BB1A91C1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Heads up to the management folk, this work look = hauntingly similar in concept to the Netconf work. Link to the draft being = discussed follows.

 

http://www.ietf.org/internet-drafts/draft-urpalainen-sim= ple-xml-patch-ops-01.txt

 

Regards, /gww

------_=_NextPart_001_01C5DFD2.BB1A91C1-- -- 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 Nov 07 15:58:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZE4h-0005Ze-Co for netconf-archive@megatron.ietf.org; Mon, 07 Nov 2005 15:58:45 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07284 for ; Mon, 7 Nov 2005 15:58:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZDvu-0001gr-AX for netconf-data@psg.com; Mon, 07 Nov 2005 20:49:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.140.192.55] (helo=zrtps0kn.nortelnetworks.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZDvs-0001f0-TP for netconf@ops.ietf.org; Mon, 07 Nov 2005 20:49:37 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jA7KnWn20090; Mon, 7 Nov 2005 15:49:32 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 'Phase 2' Editing Sessions in Vancouver Date: Mon, 7 Nov 2005 15:49:31 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4059BE614@zcarhxm2.corp.nortel.com> Thread-Topic: Netconf 'Phase 2' Editing Sessions in Vancouver Thread-Index: AcXU31ZeREYY9Pp7TSqaN6/SBb4HmAK1MrqAAQoNhnA= From: "Sharon Chisholm" To: Cc: "Netconf Data Model Discussion" Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi For those running late, we will be in the Arbutus Room, which is upstairs. We shall still meet near the bulletin board and then head up. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Chisholm, Sharon [CAR:5K50:EXCH] Sent: Wednesday, November 02, 2005 8:52 AM To: netconf@ops.ietf.org Subject: RE: Netconf 'Phase 2' Editing Sessions in Vancouver hi Ok. Let's start with the following: 1) Netconf Event Monday Afternoon Session II Meet at the bulletin board 2) Framework for Netconf Content (and other data model issues) Tuesday Afternoon Session II Meet at the bulletin board Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Chisholm, Sharon [CAR:5K50:EXCH] Sent: Wednesday, October 19, 2005 3:00 PM To: netconf@ops.ietf.org Subject: Netconf 'Phase 2' Editing Sessions in Vancouver hi I'm currently scanning the Vancouver IETF schedule for promising slots to hold a number of offline editing sessions for the Netconf Event and Netconf Content internet drafts. I am thinking we could hold quite a few sessions. The documents can be seen under 'id exists' at =09 https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dsearch_list&= s earch_job_owner=3D0&search_group_acronym=3D&search_status_id=3D&search_cu= r_sta te=3D&sub_state_id=3D6&search_filename=3Dnetconf&search_rfcnumber=3D&sear= ch_area _acronym=3D&search_button=3DSEARCH Expect updates within the next week or so. I will also post them http://standards.nortel.com/netconf/docs/IETF%2064/ Potential Timeslots (other than evenings, lunches and cookie breaks) ------------------- 1) Monday morning 2) Monday Afternoon Session II 3) Tuesday Afternoon Session II & III 4) Wednesday morning 5) Thursday morning =09 Please let me know if you are interested and what your preferred times are, as well as which documents you are interested in discussing.=20 Note that this does not preclude people sending comments on the mailing lists. Netconf content feedback can be sent to the Netconf Model list http://standards.nortel.com/netconf/index.html Netconf Event comments can perhaps be sent to this list, or if Andy and Simon object then they instead can be sent to the above list. 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: -- 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 Nov 07 20:39:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZISi-0007tp-48 for netconf-archive@megatron.ietf.org; Mon, 07 Nov 2005 20:39:48 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29685 for ; Mon, 7 Nov 2005 20:39:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZIJc-000DLK-6x for netconf-data@psg.com; Tue, 08 Nov 2005 01:30:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [47.140.192.56] (helo=zrtps0kp.nortelnetworks.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZIJb-000D7J-EL for netconf@ops.ietf.org; Tue, 08 Nov 2005 01:30:23 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jA81TsT15892 for ; Mon, 7 Nov 2005 20:29:54 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Netconf Event Message as Working Group Document Date: Mon, 7 Nov 2005 20:29:52 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4059BE81E@zcarhxm2.corp.nortel.com> Thread-Topic: Netconf Event Message as Working Group Document Thread-Index: AcXkA+qpqHd+7rcGQzaZ/phH21A1bw== From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi I'd like to request that we add the Netconf Event Messages ID (draft-chisholm-netconf-event-01.txt) as a working group document for the Netconf working group. As previously discussed, it does not require an update to the charter.=20 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 Mon Nov 07 22:48:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZKTM-0004vs-Uk for netconf-archive@megatron.ietf.org; Mon, 07 Nov 2005 22:48:37 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06602 for ; Mon, 7 Nov 2005 22:48:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZKOR-000Fg6-FX for netconf-data@psg.com; Tue, 08 Nov 2005 03:43:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZKOO-000Fex-Q4 for netconf@ops.ietf.org; Tue, 08 Nov 2005 03:43:28 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 07 Nov 2005 19:43:28 -0800 X-IronPort-AV: i="3.97,302,1125903600"; d="scan'208"; a="672671110:sNHT32409088" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA83hKKG025581; Mon, 7 Nov 2005 19:43:26 -0800 (PST) Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 19:43:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Event Message as Working Group Document Date: Mon, 7 Nov 2005 19:43:16 -0800 Message-ID: <6E21698722408147BEA594E073E2B0ABEF8163@xmb-sjc-223.amer.cisco.com> Thread-Topic: Netconf Event Message as Working Group Document Thread-Index: AcXkA+qpqHd+7rcGQzaZ/phH21A1bwAEQcgQ From: "Hector Trevino \(htrevino\)" To: "Sharon Chisholm" , X-OriginalArrivalTime: 08 Nov 2005 03:43:18.0654 (UTC) FILETIME=[8ED319E0:01C5E416] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Sharon, Agree with your suggestion. We'd like to see this work move ahead in the NETCONF WG. Hector =20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm Sent: Monday, November 07, 2005 6:30 PM To: netconf@ops.ietf.org Subject: Netconf Event Message as Working Group Document hi I'd like to request that we add the Netconf Event Messages ID (draft-chisholm-netconf-event-01.txt) as a working group document for the Netconf working group. As previously discussed, it does not require an update to the charter.=20 Sharon Chisholm Nortel 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: -- 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 Nov 07 23:04:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZKiZ-0001FM-Pr for netconf-archive@megatron.ietf.org; Mon, 07 Nov 2005 23:04:20 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07924 for ; Mon, 7 Nov 2005 23:03:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZKd7-000M0P-Ef for netconf-data@psg.com; Tue, 08 Nov 2005 03:58:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.52 (FreeBSD)) id 1EZKd6-000Lzk-FN for netconf@ops.ietf.org; Tue, 08 Nov 2005 03:58:40 +0000 Received: (qmail 6574 invoked by uid 78); 8 Nov 2005 03:58:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by mail11.netsol.inquent.com with SMTP; 8 Nov 2005 03:58:39 -0000 Message-ID: <4370226C.3020903@andybierman.com> Date: Mon, 07 Nov 2005 19:58:36 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: Netconf Event Message as Working Group Document References: <713043CE8B8E1348AF3C546DBE02C1B4059BE81E@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4059BE81E@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sharon Chisholm wrote: >hi > >I'd like to request that we add the Netconf Event Messages ID >(draft-chisholm-netconf-event-01.txt) as a working group document for >the Netconf working group. As previously discussed, it does not require >an update to the charter. > > The AD and NETCONF co-Chairs have already decided that there needs to be some implementation experience with NETCONF before we standardize extensions. Has this event-01 draft been implemented and used in any operational or even test networks? Are there a large number of WG members that think the NETCONF WG should focus on designing a new event management system at this time? Remember that our focus is configuration. Even when we had notifications in the protocol, it was by reference to RFC 3195 (syslog over beep). There are some people in the WG (including me) that would rather not reinvent syslog or SNMP notifications. I would rather that the WG focus on an access control model for NETCONF. (Design it. Implement it. Refine it. Then bring it to the IETF for standardization.) >Sharon Chisholm >Nortel >Ottawa, Ontario >Canada > > > 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 Tue Nov 08 03:04:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZOT2-0005cO-E1 for netconf-archive@megatron.ietf.org; Tue, 08 Nov 2005 03:04:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19338 for ; Tue, 8 Nov 2005 03:04:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZOLb-000Fcv-RE for netconf-data@psg.com; Tue, 08 Nov 2005 07:56:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,UNIQUE_WORDS autolearn=no version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZOLY-000FbL-HG for netconf@ops.ietf.org; Tue, 08 Nov 2005 07:56:48 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 188C34BEA7; Tue, 8 Nov 2005 08:56:47 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 01807-04; Tue, 8 Nov 2005 08:56:45 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) by hermes.iu-bremen.de (Postfix) with ESMTP id 83F294BEA2; Tue, 8 Nov 2005 08:56:45 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 0E72F526772; Tue, 8 Nov 2005 08:56:42 +0100 (CET) Date: Tue, 8 Nov 2005 08:56:42 +0100 From: Juergen Schoenwaelder To: "Hector Trevino (htrevino)" Cc: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Netconf Event Message as Working Group Document Message-ID: <20051108075642.GA3116@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "Hector Trevino (htrevino)" , Sharon Chisholm , netconf@ops.ietf.org References: <6E21698722408147BEA594E073E2B0ABEF8163@xmb-sjc-223.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6E21698722408147BEA594E073E2B0ABEF8163@xmb-sjc-223.amer.cisco.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk On Mon, Nov 07, 2005 at 07:43:16PM -0800, Hector Trevino (htrevino) wrote: > > Sharon, > > Agree with your suggestion. We'd like to see this work move ahead in the > NETCONF WG. Who is "we" here? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Nov 08 12:53:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZXej-0006xi-S5 for netconf-archive@megatron.ietf.org; Tue, 08 Nov 2005 12:53:16 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22087 for ; Tue, 8 Nov 2005 12:52:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZXWW-000GYL-Sc for netconf-data@psg.com; Tue, 08 Nov 2005 17:44:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZXWS-000GWL-MC for netconf@ops.ietf.org; Tue, 08 Nov 2005 17:44:40 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 08 Nov 2005 09:44:40 -0800 X-IronPort-AV: i="3.97,305,1125903600"; d="scan'208"; a="362378311:sNHT39097856" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA8Hhm4m004232; Tue, 8 Nov 2005 09:44:37 -0800 (PST) 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.211); Tue, 8 Nov 2005 09:44:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Event Message as Working Group Document Date: Tue, 8 Nov 2005 09:44:19 -0800 Message-ID: <6E21698722408147BEA594E073E2B0ABEF8276@xmb-sjc-223.amer.cisco.com> Thread-Topic: Netconf Event Message as Working Group Document Thread-Index: AcXkOfzep1I8aOT1QFyRP5EGS2TV+gAUYu7g From: "Hector Trevino \(htrevino\)" To: Cc: "Sharon Chisholm" , X-OriginalArrivalTime: 08 Nov 2005 17:44:22.0357 (UTC) FILETIME=[0D891850:01C5E48C] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, that would be various people at Cisco who are interested in NETCONF and think notification support is needed. Hector =20 -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 Sent: Tuesday, November 08, 2005 12:57 AM To: Hector Trevino (htrevino) Cc: Sharon Chisholm; netconf@ops.ietf.org Subject: Re: Netconf Event Message as Working Group Document On Mon, Nov 07, 2005 at 07:43:16PM -0800, Hector Trevino (htrevino) wrote: >=20 > Sharon, >=20 > Agree with your suggestion. We'd like to see this work move ahead in=20 > the NETCONF WG. Who is "we" here? /js --=20 Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Nov 08 13:08:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZXtq-0002Wg-Fl for netconf-archive@megatron.ietf.org; Tue, 08 Nov 2005 13:08:52 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23174 for ; Tue, 8 Nov 2005 13:08:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZXnh-000O4K-Do for netconf-data@psg.com; Tue, 08 Nov 2005 18:02:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZXng-000O3K-Go for netconf@ops.ietf.org; Tue, 08 Nov 2005 18:02:28 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA8I2DXc024804; Tue, 8 Nov 2005 12:02:15 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 8 Nov 2005 19:02:12 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155088210C4@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Hector Trevino (htrevino)" , j.schoenwaelder@iu-bremen.de Cc: Sharon Chisholm , netconf@ops.ietf.org Subject: RE: Netconf Event Message as Working Group Document Date: Tue, 8 Nov 2005 19:02:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-netconf@ops.ietf.org Precedence: bulk So may I assume you guys are implementing on top of an existing Cisco NetConf implementation? Bert > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Hector Trevino (htrevino) > Sent: Tuesday, November 08, 2005 18:44 > To: j.schoenwaelder@iu-bremen.de > Cc: Sharon Chisholm; netconf@ops.ietf.org > Subject: RE: Netconf Event Message as Working Group Document > > > > Hi, that would be various people at Cisco who are interested > in NETCONF > and think notification support is needed. > Hector > > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Tuesday, November 08, 2005 12:57 AM > To: Hector Trevino (htrevino) > Cc: Sharon Chisholm; netconf@ops.ietf.org > Subject: Re: Netconf Event Message as Working Group Document > > On Mon, Nov 07, 2005 at 07:43:16PM -0800, Hector Trevino (htrevino) > wrote: > > > > Sharon, > > > > Agree with your suggestion. We'd like to see this work move > ahead in > > the NETCONF WG. > > Who is "we" here? > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, > Germany > > -- > 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 Tue Nov 08 13:55:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYd8-0005jt-Bg for netconf-archive@megatron.ietf.org; Tue, 08 Nov 2005 13:55:38 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25623 for ; Tue, 8 Nov 2005 13:55:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZYW5-0000Z9-8A for netconf-data@psg.com; Tue, 08 Nov 2005 18:48:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZYW3-0000Yy-Mb for netconf@ops.ietf.org; Tue, 08 Nov 2005 18:48:19 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 08 Nov 2005 10:48:29 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA8IlqcB006840; Tue, 8 Nov 2005 10:48:26 -0800 (PST) Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 10:48:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Event Message as Working Group Document Date: Tue, 8 Nov 2005 10:48:23 -0800 Message-ID: <6E21698722408147BEA594E073E2B0ABEF8302@xmb-sjc-223.amer.cisco.com> Thread-Topic: Netconf Event Message as Working Group Document Thread-Index: AcXkjz8VNoYLzf8kR/eGdOg8djwjlwABaBLw From: "Hector Trevino \(htrevino\)" To: "Wijnen, Bert \(Bert\)" , Cc: "Sharon Chisholm" , X-OriginalArrivalTime: 08 Nov 2005 18:48:25.0923 (UTC) FILETIME=[007AB930:01C5E495] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Yes, you may assume that.=20 Hector =20 -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Tuesday, November 08, 2005 11:02 AM To: Hector Trevino (htrevino); j.schoenwaelder@iu-bremen.de Cc: Sharon Chisholm; netconf@ops.ietf.org Subject: RE: Netconf Event Message as Working Group Document So may I assume you guys are implementing on top of an existing Cisco NetConf implementation? Bert > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Hector Trevino (htrevino) > Sent: Tuesday, November 08, 2005 18:44 > To: j.schoenwaelder@iu-bremen.de > Cc: Sharon Chisholm; netconf@ops.ietf.org > Subject: RE: Netconf Event Message as Working Group Document >=20 >=20 >=20 > Hi, that would be various people at Cisco who are interested in=20 > NETCONF and think notification support is needed. > Hector > =20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Tuesday, November 08, 2005 12:57 AM > To: Hector Trevino (htrevino) > Cc: Sharon Chisholm; netconf@ops.ietf.org > Subject: Re: Netconf Event Message as Working Group Document >=20 > On Mon, Nov 07, 2005 at 07:43:16PM -0800, Hector Trevino (htrevino) > wrote: > >=20 > > Sharon, > >=20 > > Agree with your suggestion. We'd like to see this work move > ahead in > > the NETCONF WG. >=20 > Who is "we" here? >=20 > /js >=20 > --=20 > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, > Germany >=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: From owner-netconf@ops.ietf.org Tue Nov 08 14:13:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYuB-0002dW-4I for netconf-archive@megatron.ietf.org; Tue, 08 Nov 2005 14:13:15 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26721 for ; Tue, 8 Nov 2005 14:12:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZYox-0001cn-IU for netconf-data@psg.com; Tue, 08 Nov 2005 19:07:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZYow-0001cL-KD for netconf@ops.ietf.org; Tue, 08 Nov 2005 19:07:50 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jA8J7j501267; Tue, 8 Nov 2005 14:07:45 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Event Message as Working Group Document Date: Tue, 8 Nov 2005 14:07:06 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D0702C525@zcarhxm0.corp.nortel.com> Thread-Topic: Netconf Event Message as Working Group Document Thread-Index: AcXkGdFK+QXV5ZAUSrimm5gpwIwFcAAe2QSA From: "Glenn Waters" To: "Andy Bierman" , "Sharon Chisholm" Cc: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I support this working being adopted in the Netconf WG to support the line in the charter that says: "- Provides support for asynchronous notifications" Further comments inline. Regards, /gww=20 > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Andy Bierman > Sent: Monday, November 07, 2005 19:59 > To: Chisholm, Sharon [CAR:5K50:EXCH] > Cc: netconf@ops.ietf.org > Subject: Re: Netconf Event Message as Working Group Document >=20 > Sharon Chisholm wrote: >=20 > >hi > > > >I'd like to request that we add the Netconf Event Messages ID > >(draft-chisholm-netconf-event-01.txt) as a working group document for > >the Netconf working group. As previously discussed, it does not require > >an update to the charter. > > > > >=20 > The AD and NETCONF co-Chairs have already decided that there needs > to be some implementation experience with NETCONF before we > standardize extensions. >=20 > Has this event-01 draft been implemented and used in any operational > or even test networks? Are there a large number of WG members > that think the NETCONF WG should focus on designing a new event > management system at this time? 12 people were at the ad hoc editing session yesterday. These days in the IETF that should be characterized as overwhelming support. > Remember that our focus is configuration. I disagree. From the charter: "- Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data" It seems to me that we are considering data other than just config data. We also had many discussions around how to distinguish config from other data in the protocol. Read section 1.3 of the proto document. > Even when we had notifications in the protocol, > it was by reference to RFC 3195 (syslog over beep). > There are some people in the WG (including me) that > would rather not reinvent syslog or SNMP notifications. I agree that the reasons for adding events to Netconf should be made clear especially with respect to syslog.=20 If Netconf is the replacement for SNMP, as many people are thinking about, then SNMP notifications need a replacement. However, this just brings up another work item that should be tackled -- transporting SNMP managed objects over Netconf -- but this work item does not gate doing events. =20 > I would rather that the WG focus on an access control model for NETCONF. > (Design it. Implement it. Refine it. Then bring it to the IETF for > standardization.) We have a draft for events that is being edited for its third revision, seems like there is support and work going on. With respect to access control we have zero drafts. I too would like to see access control worked on but I don't see the work. > >Sharon Chisholm > >Nortel > >Ottawa, Ontario > >Canada >=20 > Andy Glenn. -- 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 Nov 08 14:15:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYvy-0002wc-T4 for netconf-archive@megatron.ietf.org; Tue, 08 Nov 2005 14:15:07 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26789 for ; Tue, 8 Nov 2005 14:14:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZYs1-0001oH-KZ for netconf-data@psg.com; Tue, 08 Nov 2005 19:11:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.52 (FreeBSD)) id 1EZYry-0001ng-OB for netconf@ops.ietf.org; Tue, 08 Nov 2005 19:10:58 +0000 Received: (qmail 23634 invoked by uid 78); 8 Nov 2005 19:10:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.58 with SMTP; 8 Nov 2005 19:10:57 -0000 Message-ID: <4370F83F.4080105@andybierman.com> Date: Tue, 08 Nov 2005 11:10:55 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hector Trevino (htrevino)" CC: "Wijnen, Bert \(Bert\)" , j.schoenwaelder@iu-bremen.de, Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Netconf Event Message as Working Group Document References: <6E21698722408147BEA594E073E2B0ABEF8302@xmb-sjc-223.amer.cisco.com> In-Reply-To: <6E21698722408147BEA594E073E2B0ABEF8302@xmb-sjc-223.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hector Trevino (htrevino) wrote: >Yes, you may assume that. > Is this syslog, SNMP notification, or something new? IMO, notifications in the original charter are not clearly enough specified to be useful in this debate. The first debate I want to have is whether NETCONF should invent a new event system or adopt/invent NETCONF XML encodings of syslog and/or SNMP notifications. Anyone one the list with an opinion, please speak up! > >Hector > > Andy > > >-----Original Message----- >From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >Sent: Tuesday, November 08, 2005 11:02 AM >To: Hector Trevino (htrevino); j.schoenwaelder@iu-bremen.de >Cc: Sharon Chisholm; netconf@ops.ietf.org >Subject: RE: Netconf Event Message as Working Group Document > >So may I assume you guys are implementing on top of an existing Cisco >NetConf implementation? > >Bert > > > >>-----Original Message----- >>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On >>Behalf Of Hector Trevino (htrevino) >>Sent: Tuesday, November 08, 2005 18:44 >>To: j.schoenwaelder@iu-bremen.de >>Cc: Sharon Chisholm; netconf@ops.ietf.org >>Subject: RE: Netconf Event Message as Working Group Document >> >> >> >>Hi, that would be various people at Cisco who are interested in >>NETCONF and think notification support is needed. >>Hector >> >> >>-----Original Message----- >>From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] >>Sent: Tuesday, November 08, 2005 12:57 AM >>To: Hector Trevino (htrevino) >>Cc: Sharon Chisholm; netconf@ops.ietf.org >>Subject: Re: Netconf Event Message as Working Group Document >> >>On Mon, Nov 07, 2005 at 07:43:16PM -0800, Hector Trevino (htrevino) >>wrote: >> >> >>>Sharon, >>> >>>Agree with your suggestion. We'd like to see this work move >>> >>> >>ahead in >> >> >>>the NETCONF WG. >>> >>> >>Who is "we" here? >> >>/js >> >>-- >>Juergen Schoenwaelder International University Bremen >> P.O. Box 750 561, >>28725 Bremen, >>Germany >> >>-- >>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 Tue Nov 08 14:49:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZSs-0007aI-4x for netconf-archive@megatron.ietf.org; Tue, 08 Nov 2005 14:49:06 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29302 for ; Tue, 8 Nov 2005 14:48:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZZLU-0003ZI-Vc for netconf-data@psg.com; Tue, 08 Nov 2005 19:41:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.155.97] (helo=swip.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZZLT-0003Z5-V4 for netconf@ops.ietf.org; Tue, 08 Nov 2005 19:41:28 +0000 X-T2-Posting-ID: P5HZhTV1iTSvFccgWTR5dA== Received: from [213.100.166.180] (HELO localhost) by mailfe12.swip.net (CommuniGate Pro SMTP 4.3.8) with ESMTP id 45166614 for netconf@ops.ietf.org; Tue, 08 Nov 2005 20:41:26 +0100 Date: Tue, 08 Nov 2005 20:41:18 +0100 (CET) Message-Id: <20051108.204118.119867355.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: more comments on draft-ietf-netconf-prot-09 From: Martin Bjorklund In-Reply-To: <435ECD4D.1060103@andybierman.com> References: <435E5E44.3090300@andybierman.com> <20051025.200640.11636521.mbj@tail-f.com> <435ECD4D.1060103@andybierman.com> X-Mailer: Mew version 2.2rc2-mbj1 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 Content-Transfer-Encoding: 7bit Hi, I have a few more comments and questions. 1. What does it mean to lock a remote configuration file, pointed to by a URL? Maybe the lock opertaion should have the same restriction as e.g. edit-config, i.e. the URL has to be a local file? 2. If a manager tries to do an edit-config which contains some error, is it correct to assume that 'stop-on-error' (default) is supposed to actually modify the configuration so that it is left in a possibly inconsistent state? If this is correct, under which cirumstances is this behaviour something the manager would choose? Would you consider an implementation that did NOT allow edit-config with errors when trying to modify the running configuration non-compliant? Today, our implementation will refuse to change the running config if an edit-config results in an invalid configuration state (even if error-option is ignore-error and test-option is set). Why is this behaviour controlled by the manager, not the agent? 3. [minor] Section 8.3.1 mentions a :lock capability. Is it just a remainder from when lock was a capability? /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 Tue Nov 08 14:49:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZTQ-0007h2-2W for netconf-archive@megatron.ietf.org; Tue, 08 Nov 2005 14:49:40 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29383 for ; Tue, 8 Nov 2005 14:49:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZZJf-0003Rr-W4 for netconf-data@psg.com; Tue, 08 Nov 2005 19:39:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.52 (FreeBSD)) id 1EZZJf-0003Rg-60 for netconf@ops.ietf.org; Tue, 08 Nov 2005 19:39:35 +0000 Received: (qmail 5152 invoked by uid 78); 8 Nov 2005 19:39:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by mail10.netsol.inquent.com with SMTP; 8 Nov 2005 19:39:34 -0000 Message-ID: <4370FEF4.2070201@andybierman.com> Date: Tue, 08 Nov 2005 11:39:32 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Glenn Waters CC: Sharon Chisholm , netconf@ops.ietf.org, Bert Wijnen , David Kessens , Simon Leinen Subject: Re: Netconf Event Message as Working Group Document References: <085091CB2CA14E4B8B163FFC37C84E9D0702C525@zcarhxm0.corp.nortel.com> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D0702C525@zcarhxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Glenn Waters wrote: >I support this working being adopted in the Netconf WG to support the >line in the charter that says: > > I don't think charter word-picking really helps here. Ultimately, this is a decision for Bert and David to make. I personally do not think the NETCONF WG should invent a new notification information model at this time. I could support a plan to transport syslog and SNMP notifications over NETCONF, but spending major energy on 'events' before finishing the security work (access control) is something I can't really support. BTW, solving access control also solves the partial lock problem. If AC is done correctly, that feature will fall out for free. I can't imagine the IESG will prioritize re-invention of syslog/SNMP over configurable access control for NETCONF RPC methods and data models either, but who knows. Andy >"- Provides support for asynchronous notifications" > >Further comments inline. > >Regards, /gww > > > >>-----Original Message----- >>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] >> >> >On > > >>Behalf Of Andy Bierman >>Sent: Monday, November 07, 2005 19:59 >>To: Chisholm, Sharon [CAR:5K50:EXCH] >>Cc: netconf@ops.ietf.org >>Subject: Re: Netconf Event Message as Working Group Document >> >>Sharon Chisholm wrote: >> >> >> >>>hi >>> >>>I'd like to request that we add the Netconf Event Messages ID >>>(draft-chisholm-netconf-event-01.txt) as a working group document for >>>the Netconf working group. As previously discussed, it does not >>> >>> >require > > >>>an update to the charter. >>> >>> >>> >>> >>The AD and NETCONF co-Chairs have already decided that there needs >>to be some implementation experience with NETCONF before we >>standardize extensions. >> >>Has this event-01 draft been implemented and used in any operational >>or even test networks? Are there a large number of WG members >>that think the NETCONF WG should focus on designing a new event >>management system at this time? >> >> > >12 people were at the ad hoc editing session yesterday. These days in >the IETF that should be characterized as overwhelming support. > > > >>Remember that our focus is configuration. >> >> > >I disagree. From the charter: > >"- Provides retrieval mechanisms which can differentiate between > configuration data and non-configuration data" > >It seems to me that we are considering data other than just config data. >We also had many discussions around how to distinguish config from other >data in the protocol. Read section 1.3 of the proto document. > > > >>Even when we had notifications in the protocol, >>it was by reference to RFC 3195 (syslog over beep). >>There are some people in the WG (including me) that >>would rather not reinvent syslog or SNMP notifications. >> >> > >I agree that the reasons for adding events to Netconf should be made >clear especially with respect to syslog. > >If Netconf is the replacement for SNMP, as many people are thinking >about, then SNMP notifications need a replacement. However, this just >brings up another work item that should be tackled -- transporting SNMP >managed objects over Netconf -- but this work item does not gate doing >events. > > > >>I would rather that the WG focus on an access control model for >> >> >NETCONF. > > >>(Design it. Implement it. Refine it. Then bring it to the IETF for >>standardization.) >> >> > >We have a draft for events that is being edited for its third revision, >seems like there is support and work going on. > >With respect to access control we have zero drafts. I too would like to >see access control worked on but I don't see the work. > > > >>>Sharon Chisholm >>>Nortel >>>Ottawa, Ontario >>>Canada >>> >>> >>Andy >> >> > >Glenn. > >-- >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 Tue Nov 08 14:59:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZcl-0002IQ-4R for netconf-archive@megatron.ietf.org; Tue, 08 Nov 2005 14:59:19 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29972 for ; Tue, 8 Nov 2005 14:58:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZZXS-0004LS-HM for netconf-data@psg.com; Tue, 08 Nov 2005 19:53:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.52 (FreeBSD)) id 1EZZXR-0004LG-Q3 for netconf@ops.ietf.org; Tue, 08 Nov 2005 19:53:49 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id jA8JrMBm047128; Tue, 8 Nov 2005 11:53:22 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jA8JrLG98277; Tue, 8 Nov 2005 11:53:21 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id jA8JwYYE039129; Tue, 8 Nov 2005 14:58:35 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200511081958.jA8JwYYE039129@idle.juniper.net> To: Andy Bierman cc: "Hector Trevino (htrevino)" , "Wijnen, Bert \(Bert\)" , j.schoenwaelder@iu-bremen.de, Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Netconf Event Message as Working Group Document In-Reply-To: Your message of "Tue, 08 Nov 2005 11:10:55 PST." <4370F83F.4080105@andybierman.com> Date: Tue, 08 Nov 2005 14:58:34 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Andy Bierman writes: >Anyone one the list with an opinion, please speak up! Hey, that's me!! ;^) I do feel that we need more than syslog. In particular, I want to be able to say "give me all the events from the last 20 minutes that relate to interface fe-1/2/3.0". So I need to be able to ship specific fields in addition to the message text. Consider: RPD_RSVP_NBRUP farmer-john rpd 10.5.14.2 fe-1/3/0.0 RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0 Yes, I hear you gag on the obnoxious verbosity compared with the traditional syslog line: Oct 18 16:01:37 farmer-john rpd[2958]: RPD_RSVP_NBRUP: RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0 And yes, I will be trafficing and storing these messages _far_ more than I'll be searching them, so the wasted bandwidth and storage _does_ matter. The bit of functionality I do want is being able to say: notification[starts-with(data/interface, $device)] and get better results than "grep $device /var/log/messages". The new XML-ified syslog formats don't give me any of the above. They only put the message text in a xml element. I still haven't read the netconf-event spec, but skimming it, I don't see much about real data content. I do see the "rpc-one-way" which seems wildly confusing, as it's not an RPC at all. It's an async message from the server to the client, where an RPC is a remote procedure call from the client to the server. Anyway, the question to me is how can I break out my individual fields (the data I care most about) without making 400 byte messages? I don't think the answer is XML or ASN.1, or YAML. But some simple ascii field encoding that will support later operations that are rare, complex, and must be accurate. Thanks, Phil -- 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 Nov 08 15:14:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZr8-0006EM-SH for netconf-archive@megatron.ietf.org; Tue, 08 Nov 2005 15:14:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00788 for ; Tue, 8 Nov 2005 15:13:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZZmM-0005Ah-Rq for netconf-data@psg.com; Tue, 08 Nov 2005 20:09:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.52 (FreeBSD)) id 1EZZmM-0005AW-4x for netconf@ops.ietf.org; Tue, 08 Nov 2005 20:09:14 +0000 Received: (qmail 6246 invoked by uid 78); 8 Nov 2005 20:09:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by mail5.netsol.inquent.com with SMTP; 8 Nov 2005 20:09:07 -0000 Message-ID: <437105E2.4030806@andybierman.com> Date: Tue, 08 Nov 2005 12:09:06 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Glenn Waters CC: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Netconf Event Message as Working Group Document References: <085091CB2CA14E4B8B163FFC37C84E9D0702C525@zcarhxm0.corp.nortel.com> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D0702C525@zcarhxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Glenn Waters wrote: >I support this working being adopted in the Netconf WG to support the >line in the charter that says: > >"- Provides support for asynchronous notifications" > > > 2 more comments: 1) The charter text above is very vague. From the XMLCONF days on through the time notifications were taken out of the NETCONF protocol, our entire (phase 1) work effort related to this charter item was to add a sentence pointing to the BEEP profile for RFC 3195. IMO, adoption of Sharon's document is not covered by this charter item, and would require better charter text, WG approval, and AD approval. >.... >>I would rather that the WG focus on an access control model for >> >> >NETCONF. > > >>(Design it. Implement it. Refine it. Then bring it to the IETF for >>standardization.) >> >> > >We have a draft for events that is being edited for its third revision, >seems like there is support and work going on. > >With respect to access control we have zero drafts. I too would like to >see access control worked on but I don't see the work. > > I would like to see "rough consensus AND RUNNING CODE", not just a draft. IMO, we should get back to that in the IETF. > > >>>Sharon Chisholm >>>Nortel >>>Ottawa, Ontario >>>Canada >>> >>> >>Andy >> >> > >Glenn. > > 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 Tue Nov 08 15:19:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZwM-0007sd-W3 for netconf-archive@megatron.ietf.org; Tue, 08 Nov 2005 15:19:35 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01019 for ; Tue, 8 Nov 2005 15:19:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZZrL-0005TS-K3 for netconf-data@psg.com; Tue, 08 Nov 2005 20:14:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.52 (FreeBSD)) id 1EZZrK-0005TG-Qb for netconf@ops.ietf.org; Tue, 08 Nov 2005 20:14:23 +0000 Received: (qmail 21637 invoked by uid 78); 8 Nov 2005 20:14:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by mail13.netsol.inquent.com with SMTP; 8 Nov 2005 20:14:22 -0000 Message-ID: <4371071C.7030108@andybierman.com> Date: Tue, 08 Nov 2005 12:14:20 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phil Shafer CC: "Hector Trevino (htrevino)" , "Wijnen, Bert \(Bert\)" , j.schoenwaelder@iu-bremen.de, Sharon Chisholm , netconf@ops.ietf.org Subject: Re: Netconf Event Message as Working Group Document References: <200511081958.jA8JwYYE039129@idle.juniper.net> In-Reply-To: <200511081958.jA8JwYYE039129@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Phil Shafer wrote: >Andy Bierman writes: > > >>Anyone one the list with an opinion, please speak up! >> >> > >Hey, that's me!! ;^) > >I do feel that we need more than syslog. In particular, I want >to be able to say "give me all the events from the last 20 minutes >that relate to interface fe-1/2/3.0". So I need to be able to >ship specific fields in addition to the message text. Consider: > > > > RPD_RSVP_NBRUP > farmer-john > rpd > > 10.5.14.2 > fe-1/3/0.0 > > RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0 > > >Yes, I hear you gag on the obnoxious verbosity compared with the >traditional syslog line: > >Oct 18 16:01:37 farmer-john rpd[2958]: RPD_RSVP_NBRUP: RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0 > > XML-ification of syslog contents is what I meant in my last message. IMO, what you describe here is not re-inventing syslog but rather mapping syslog string message format to NETCONF XML format in a predictable way. (I hope that's what you meant :-) >Thanks, > Phil > > > 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 Tue Nov 08 16:20:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZatg-0002hd-An for netconf-archive@megatron.ietf.org; Tue, 08 Nov 2005 16:20:53 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06465 for ; Tue, 8 Nov 2005 16:20:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZan6-0008lP-49 for netconf-data@psg.com; Tue, 08 Nov 2005 21:14:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [63.240.77.84] (helo=sccrmhc14.comcast.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZan3-0008l8-HV for netconf@ops.ietf.org; Tue, 08 Nov 2005 21:14:01 +0000 Received: from djyxpy41 (pp105-206.bctel.ca[209.52.105.206]) by comcast.net (sccrmhc14) with SMTP id <20051108211354014002d2bde>; Tue, 8 Nov 2005 21:14:00 +0000 Reply-To: From: "David B Harrington" To: "'Andy Bierman'" , "'Hector Trevino \(htrevino\)'" Cc: "'Wijnen, Bert \(Bert\)'" , , "'Sharon Chisholm'" , Subject: RE: Netconf Event Message as Working Group Document Date: Tue, 8 Nov 2005 13:13:26 -0800 Message-ID: <00c701c5e4a9$4fa50d30$ce6934d1@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4370F83F.4080105@andybierman.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXkmLv8+Iu5w3qIT8i0MK+fY7s0XgAAPAXQ Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have an opinion. I think there is real value in being able to correlate snmp notifications with syslog messages, and likely with other event-driven communications. I have concerns with developing another type of notificaiton before integrating with existing solutions. The ISMS WG was chartered because operators expressed an interest in not having to deal with yet-another solution for security. I have not seen strong demand for yet-another solution for notifications. The event draft invents a new format with new content. There appears to be some correlation with ITU-style of events management, and an effort to reuse designs from ITU and other SDOs may be an important benefit, but I'd rather see us address reuse of/correlation with our own standards first. My professional role is typically as an NM architect for an equipment vendor, and I would have trouble evangelizing the adoption of this technology in my employer's devices and application without having a much stronger case made for the benefits of this new work compared to existing notification solutions. If a proposed event messaging solution provided a means for carrying SNMP notifications and syslog messages and a means to correlate them (e.g. with timestamps or event IDs), that would be a benefit I could try to sell as a benefit to customers. A tie-in to ITU-style events and alarms might be an additional benefit I might be able to evangelize. I am not convinced the current draft provide thos benefits, but it is possible they could be added if consensus was to do so. One of the justification for netconf is its textual format - explicitly because operators want to be able to save configurations in source code control systems that cannot handle binary, so those configurations can be distributed to multiple endpoints after modification using standard text-editing tools. I don't see how defining notifications/events in XML helps solve that problem. I don't want to say we should not accept these documents, but neither do I want to say we should. I was one of the attendees to the editing session, and I went to understand what progress has been made, as did others. I don't think there has been adequate demonstration of the need for this work; more work is needed. I have difficulty asking a product manager to add this new feature to equipment without some proof of value or demand, especially since netconf itself has not yet been proven useful to or in demand by operators. So far, netconf has not been successfully tested for interoperability, largely because there are no vendor-neutral data models to test with. I think that is more important to establish some basic vendor-neutral data models than to add new features. The success of SNMP was partly because there were vendor-neutral mib modules to work with. But I have a vendor's perspective, and we really should get the operator view. Do operators want another information/data model for events? Do they want the correlation between SNMP, Netconf, and syslog events? Is this more important than establishing a mechanism for standardizing data modeling? Is it important to operators to be able to access SNMP data via netconf? David Harrington dbharrington@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Tuesday, November 08, 2005 11:11 AM > To: Hector Trevino (htrevino) > Cc: Wijnen, Bert (Bert); j.schoenwaelder@iu-bremen.de; Sharon > Chisholm; netconf@ops.ietf.org > Subject: Re: Netconf Event Message as Working Group Document > > Hector Trevino (htrevino) wrote: > > >Yes, you may assume that. > > > Is this syslog, SNMP notification, or something new? > > IMO, notifications in the original charter are not clearly > enough specified > to be useful in this debate. The first debate I want to have > is whether NETCONF should invent a new event system > or adopt/invent NETCONF XML encodings of syslog and/or SNMP > notifications. > > Anyone one the list with an opinion, please speak up! > > > > >Hector > > > > > > Andy > > > > > > >-----Original Message----- > >From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > >Sent: Tuesday, November 08, 2005 11:02 AM > >To: Hector Trevino (htrevino); j.schoenwaelder@iu-bremen.de > >Cc: Sharon Chisholm; netconf@ops.ietf.org > >Subject: RE: Netconf Event Message as Working Group Document > > > >So may I assume you guys are implementing on top of an existing Cisco > >NetConf implementation? > > > >Bert > > > > > > > >>-----Original Message----- > >>From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org]On > >>Behalf Of Hector Trevino (htrevino) > >>Sent: Tuesday, November 08, 2005 18:44 > >>To: j.schoenwaelder@iu-bremen.de > >>Cc: Sharon Chisholm; netconf@ops.ietf.org > >>Subject: RE: Netconf Event Message as Working Group Document > >> > >> > >> > >>Hi, that would be various people at Cisco who are interested in > >>NETCONF and think notification support is needed. > >>Hector > >> > >> > >>-----Original Message----- > >>From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > >>Sent: Tuesday, November 08, 2005 12:57 AM > >>To: Hector Trevino (htrevino) > >>Cc: Sharon Chisholm; netconf@ops.ietf.org > >>Subject: Re: Netconf Event Message as Working Group Document > >> > >>On Mon, Nov 07, 2005 at 07:43:16PM -0800, Hector Trevino (htrevino) > >>wrote: > >> > >> > >>>Sharon, > >>> > >>>Agree with your suggestion. We'd like to see this work move > >>> > >>> > >>ahead in > >> > >> > >>>the NETCONF WG. > >>> > >>> > >>Who is "we" here? > >> > >>/js > >> > >>-- > >>Juergen Schoenwaelder International > University Bremen > >> P.O. Box 750 561, > >>28725 Bremen, > >>Germany > >> > >>-- > >>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: > -- 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 Nov 08 16:41:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZbDd-0008S5-3H for netconf-archive@megatron.ietf.org; Tue, 08 Nov 2005 16:41:29 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07659 for ; Tue, 8 Nov 2005 16:41:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZb8z-000A3E-Cl for netconf-data@psg.com; Tue, 08 Nov 2005 21:36:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZb8y-000A33-Gq for netconf@ops.ietf.org; Tue, 08 Nov 2005 21:36:40 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 08 Nov 2005 13:36:40 -0800 X-IronPort-AV: i="3.97,305,1125903600"; d="scan'208"; a="228229015:sNHT44319204" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jA8LZwaH012381; Tue, 8 Nov 2005 13:36:37 -0800 (PST) Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 13:36:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Event Message as Working Group Document Date: Tue, 8 Nov 2005 13:36:35 -0800 Message-ID: <6E21698722408147BEA594E073E2B0ABEF845F@xmb-sjc-223.amer.cisco.com> Thread-Topic: Netconf Event Message as Working Group Document Thread-Index: AcXkmDCECT2BFGHfQIKYEbI7zzEZdwAELvHA From: "Hector Trevino \(htrevino\)" To: "Andy Bierman" Cc: "Wijnen, Bert \(Bert\)" , , "Sharon Chisholm" , X-OriginalArrivalTime: 08 Nov 2005 21:36:36.0640 (UTC) FILETIME=[7F03F200:01C5E4AC] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable See in-line Hector =20 -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com]=20 Sent: Tuesday, November 08, 2005 12:11 PM To: Hector Trevino (htrevino) Cc: Wijnen, Bert (Bert); j.schoenwaelder@iu-bremen.de; Sharon Chisholm; netconf@ops.ietf.org Subject: Re: Netconf Event Message as Working Group Document Hector Trevino (htrevino) wrote: >Yes, you may assume that. > Is this syslog, SNMP notification, or something new? HT: You could say that this is a combination of syslog and something new. syslog has been around for a long time, people will continue to use it and there are some things that could/should be re-used. However, syslog alone is not sufficient for many reasons. So, if you look at Appendix D of the netconf-event-01 you'll see there is a proposal for a) re-using some syslog field definitions (semantics) and b) being able to carry syslog messages within a NETCONF notification. The latter provides a migration path to/when XML notifications are widely available, co-existence, etc.=20 IMO, notifications in the original charter are not clearly enough specified to be useful in this debate. HT: Ok The first debate I want to have is whether NETCONF should invent a new event system or adopt/invent NETCONF XML encodings of syslog and/or SNMP notifications. HT: There are at least two maybe three parts to this:=20 a) the NETCONF protocol extensions=20 b) the event framework - this and the previous are within the scope of the current document=20 c) the event types/classes and their content - this is not dependent on NETCONF but this is a critical part and should be done. Ideally you wouldn't want client applications to have to support multiple management protocols. It happens today but I believe the goal should be to avoid that. If you agree with that then points a and b above are needed. In addition to that there are shortcomings in both of the two possibilities you list above.=20 The last point (c) is currently not addressed in existing work. syslog covers some things, SNMP covers others but there isn't a single specification for event types and their contents. So, I think this work also needs to be done. I'm not suggesting re-inventing things since there's much of this already done so existing specifications may be re-used to generate this new spec.=20 Hector =20 Anyone one the list with an opinion, please speak up! >=20 >Hector > =20 > Andy >=20 > >-----Original Message----- >From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >Sent: Tuesday, November 08, 2005 11:02 AM >To: Hector Trevino (htrevino); j.schoenwaelder@iu-bremen.de >Cc: Sharon Chisholm; netconf@ops.ietf.org >Subject: RE: Netconf Event Message as Working Group Document > >So may I assume you guys are implementing on top of an existing Cisco=20 >NetConf implementation? > >Bert > > =20 > >>-----Original Message----- >>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On >>Behalf Of Hector Trevino (htrevino) >>Sent: Tuesday, November 08, 2005 18:44 >>To: j.schoenwaelder@iu-bremen.de >>Cc: Sharon Chisholm; netconf@ops.ietf.org >>Subject: RE: Netconf Event Message as Working Group Document >> >> >> >>Hi, that would be various people at Cisco who are interested in=20 >>NETCONF and think notification support is needed. >>Hector >> =20 >> >>-----Original Message----- >>From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] >>Sent: Tuesday, November 08, 2005 12:57 AM >>To: Hector Trevino (htrevino) >>Cc: Sharon Chisholm; netconf@ops.ietf.org >>Subject: Re: Netconf Event Message as Working Group Document >> >>On Mon, Nov 07, 2005 at 07:43:16PM -0800, Hector Trevino (htrevino) >>wrote: >> =20 >> >>>Sharon, >>> >>>Agree with your suggestion. We'd like to see this work move >>> =20 >>> >>ahead in >> =20 >> >>>the NETCONF WG. >>> =20 >>> >>Who is "we" here? >> >>/js >> >>--=20 >>Juergen Schoenwaelder International University Bremen >> P.O. Box 750 561,=20 >>28725 Bremen, >>Germany >> >>-- >>to unsubscribe send a message to netconf-request@ops.ietf.org with the >> =20 >> > > =20 > >>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=20 >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: From owner-netconf@ops.ietf.org Tue Nov 08 17:00:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZbVw-00052v-ER for netconf-archive@megatron.ietf.org; Tue, 08 Nov 2005 17:00:24 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08586 for ; Tue, 8 Nov 2005 16:59:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZbP2-000BHR-AP for netconf-data@psg.com; Tue, 08 Nov 2005 21:53:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZbOy-000BH6-KN for netconf@ops.ietf.org; Tue, 08 Nov 2005 21:53:12 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 08 Nov 2005 13:53:12 -0800 X-IronPort-AV: i="3.97,305,1125903600"; d="scan'208"; a="362503883:sNHT40366248" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA8Lr2ZK020402; Tue, 8 Nov 2005 13:53:09 -0800 (PST) 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.211); Tue, 8 Nov 2005 13:53:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Event Message as Working Group Document Date: Tue, 8 Nov 2005 13:53:00 -0800 Message-ID: <6E21698722408147BEA594E073E2B0ABEF8481@xmb-sjc-223.amer.cisco.com> Thread-Topic: Netconf Event Message as Working Group Document Thread-Index: AcXkmLv8+Iu5w3qIT8i0MK+fY7s0XgAAPAXQAAS54BA= From: "Hector Trevino \(htrevino\)" To: , "Andy Bierman" Cc: "Wijnen, Bert \(Bert\)" , , "Sharon Chisholm" , X-OriginalArrivalTime: 08 Nov 2005 21:53:00.0681 (UTC) FILETIME=[C98CAF90:01C5E4AE] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable in-line Hector =20 -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net]=20 Sent: Tuesday, November 08, 2005 2:13 PM To: 'Andy Bierman'; Hector Trevino (htrevino) Cc: 'Wijnen, Bert (Bert)'; j.schoenwaelder@iu-bremen.de; 'Sharon Chisholm'; netconf@ops.ietf.org Subject: RE: Netconf Event Message as Working Group Document Hi, I have an opinion. I think there is real value in being able to correlate snmp notifications with syslog messages, and likely with other event-driven communications. HT: Agree. One of the appendices mentions this and has a description of an Event Id field for this purpose.=20 I have concerns with developing another type of notificaiton before integrating with existing solutions. The ISMS WG was chartered because operators expressed an interest in not having to deal with yet-another solution for security. I have not seen strong demand for yet-another solution for notifications. HT:=20 The event draft invents a new format with new content. There appears to be some correlation with ITU-style of events management, and an effort to reuse designs from ITU and other SDOs may be an important benefit, but I'd rather see us address reuse of/correlation with our own standards first. HT: I'd say that both re-use of non-IETF & IETF standards was attempted in the doc.=20 My professional role is typically as an NM architect for an equipment vendor, and I would have trouble evangelizing the adoption of this technology in my employer's devices and application without having a much stronger case made for the benefits of this new work compared to existing notification solutions. HT: OK If a proposed event messaging solution provided a means for carrying SNMP notifications and syslog messages and a means to correlate them (e.g. with timestamps or event IDs), that would be a benefit I could try to sell as a benefit to customers. A tie-in to ITU-style events and alarms might be an additional benefit I might be able to evangelize. I am not convinced the current draft provide thos benefits, but it is possible they could be added if consensus was to do so. HT: The doc does not address SNMP but does address syslog (appendix proposal). The tie to ITU event definitions is also there. Perhaps things could be clarified/expanded upon but the subjects are covered.=20 One of the justification for netconf is its textual format - explicitly because operators want to be able to save configurations in source code control systems that cannot handle binary, so those configurations can be distributed to multiple endpoints after modification using standard text-editing tools. I don't see how defining notifications/events in XML helps solve that problem.=20 HT: NETCONF does not specify the payload of the operations - it could be XML or it could be plain text. The operations are in XML and assuming that over time a data/info model is defined using XML then it makes sense to also define notifications in XML. The important points are that a) everything is defined in the same manner and b) that it is well defined/structured (schema) and simplifies handling/parsing of the message.=20 I don't want to say we should not accept these documents, but neither do I want to say we should. I was one of the attendees to the editing session, and I went to understand what progress has been made, as did others. I don't think there has been adequate demonstration of the need for this work; more work is needed. I have difficulty asking a product manager to add this new feature to equipment without some proof of value or demand, especially since netconf itself has not yet been proven useful to or in demand by operators. HT: OK So far, netconf has not been successfully tested for interoperability, largely because there are no vendor-neutral data models to test with. I think that is more important to establish some basic vendor-neutral data models than to add new features. The success of SNMP was partly because there were vendor-neutral mib modules to work with.=20 HT: Mostly agree. The models are necessary if any sort of interoperability is ever to be achieved. The notifications are needed to provide a complete solution and I think both are needed.=20 But I have a vendor's perspective, and we really should get the operator view. Do operators want another information/data model for events? Do they want the correlation between SNMP, Netconf, and syslog events? Is this more important than establishing a mechanism for standardizing data modeling? Is it important to operators to be able to access SNMP data via netconf? HT: Based on what I've seen, people use syslog because there is nothing better that has as complete coverage. Where available, people want to use SNMP because things are well defined/structured (data model part). So, something is needed that covers both. Yes, I know that defining the events alone won't solve the problem but I think it's a step in the right direction. Hector David Harrington dbharrington@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Tuesday, November 08, 2005 11:11 AM > To: Hector Trevino (htrevino) > Cc: Wijnen, Bert (Bert); j.schoenwaelder@iu-bremen.de; Sharon=20 > Chisholm; netconf@ops.ietf.org > Subject: Re: Netconf Event Message as Working Group Document >=20 > Hector Trevino (htrevino) wrote: >=20 > >Yes, you may assume that. > > > Is this syslog, SNMP notification, or something new? >=20 > IMO, notifications in the original charter are not clearly enough=20 > specified to be useful in this debate. The first debate I want to=20 > have is whether NETCONF should invent a new event system or=20 > adopt/invent NETCONF XML encodings of syslog and/or SNMP=20 > notifications. >=20 > Anyone one the list with an opinion, please speak up! >=20 > >=20 > >Hector > > =20 > > >=20 > Andy >=20 > >=20 > > > >-----Original Message----- > >From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > >Sent: Tuesday, November 08, 2005 11:02 AM > >To: Hector Trevino (htrevino); j.schoenwaelder@iu-bremen.de > >Cc: Sharon Chisholm; netconf@ops.ietf.org > >Subject: RE: Netconf Event Message as Working Group Document > > > >So may I assume you guys are implementing on top of an existing Cisco > >NetConf implementation? > > > >Bert > > > > =20 > > > >>-----Original Message----- > >>From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org]On > >>Behalf Of Hector Trevino (htrevino) > >>Sent: Tuesday, November 08, 2005 18:44 > >>To: j.schoenwaelder@iu-bremen.de > >>Cc: Sharon Chisholm; netconf@ops.ietf.org > >>Subject: RE: Netconf Event Message as Working Group Document > >> > >> > >> > >>Hi, that would be various people at Cisco who are interested in=20 > >>NETCONF and think notification support is needed. > >>Hector > >> =20 > >> > >>-----Original Message----- > >>From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > >>Sent: Tuesday, November 08, 2005 12:57 AM > >>To: Hector Trevino (htrevino) > >>Cc: Sharon Chisholm; netconf@ops.ietf.org > >>Subject: Re: Netconf Event Message as Working Group Document > >> > >>On Mon, Nov 07, 2005 at 07:43:16PM -0800, Hector Trevino (htrevino) > >>wrote: > >> =20 > >> > >>>Sharon, > >>> > >>>Agree with your suggestion. We'd like to see this work move > >>> =20 > >>> > >>ahead in > >> =20 > >> > >>>the NETCONF WG. > >>> =20 > >>> > >>Who is "we" here? > >> > >>/js > >> > >>--=20 > >>Juergen Schoenwaelder International=20 > University Bremen > >> P.O. Box 750 561,=20 > >>28725 Bremen, > >>Germany > >> > >>-- > >>to unsubscribe send a message to > netconf-request@ops.ietf.org with the > >> =20 > >> > > > > =20 > > > >>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=20 > >the word 'unsubscribe' in a single line as the message text body. > >archive: > > > > > > =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: From owner-netconf@ops.ietf.org Wed Nov 16 03:25:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcIcA-0005tv-Bk for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 03:25:58 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08750 for ; Wed, 16 Nov 2005 03:25:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcITg-0001ID-Eu for netconf-data@psg.com; Wed, 16 Nov 2005 08:17:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcITf-0001Hg-9W for netconf@ops.ietf.org; Wed, 16 Nov 2005 08:17:11 +0000 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0F96C1339 for ; Wed, 16 Nov 2005 09:17:10 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Nov 2005 09:16:03 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Nov 2005 09:16:03 +0100 Message-ID: <437AEAC3.90206@ericsson.com> Date: Wed, 16 Nov 2005 09:16:03 +0100 From: Balazs Lengyel User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org, David Partain Subject: Transaction support in Netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2005 08:16:03.0609 (UTC) FILETIME=[FC671090:01C5EA85] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello All, I am investigating transaction support in Netconf. One way to handle this is to use an edit-config operation with the test=test-then-set and error=rollback options. This however raises some questions as this functionality covers only a single RPC request: 1) How big can an RPC request be ? Any limit ? 2) If I have a big configuration tree is it allowed to modify to independent parts of the configuration tree in one RPC request (e.g. add a new interface and switch on and configure OSPF in on request) ? Balazs -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager & AXD Operational Suite (AOS) OPM ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- 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 Wed Nov 16 03:41:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcIqy-0001T0-93 for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 03:41:16 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09661 for ; Wed, 16 Nov 2005 03:40:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcIlw-0003a4-4y for netconf-data@psg.com; Wed, 16 Nov 2005 08:36:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcIlv-0003Zt-Dw for netconf@ops.ietf.org; Wed, 16 Nov 2005 08:36:03 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A290D4BF4C; Wed, 16 Nov 2005 09:36:02 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 28016-04; Wed, 16 Nov 2005 09:36:01 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 4F47B4BD3D; Wed, 16 Nov 2005 09:36:01 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 2430052AF50; Wed, 16 Nov 2005 09:35:58 +0100 (CET) Date: Wed, 16 Nov 2005 09:35:58 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Cc: netconf@ops.ietf.org, David Partain Subject: Re: Transaction support in Netconf Message-ID: <20051116083558.GA8755@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Balazs Lengyel , netconf@ops.ietf.org, David Partain References: <437AEAC3.90206@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <437AEAC3.90206@ericsson.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk On Wed, Nov 16, 2005 at 09:16:03AM +0100, Balazs Lengyel wrote: > Hello All, > I am investigating transaction support in Netconf. One way to handle this > is to use an edit-config operation with the test=test-then-set and > error=rollback options. This however raises some questions as this > functionality covers only a single RPC request: > 1) How big can an RPC request be ? Any limit ? I think the protocol does not specify a limit. However, concrete implementations may have specific limits (after all, memory is usually not unlimited). > 2) If I have a big configuration tree is it allowed to modify to > independent parts of the configuration tree in one RPC request > (e.g. add a new interface and switch on and configure OSPF in on > request) ? I think the answer here is that this is specifically allowed. The other option to address your requirement is to use the candidate capability. This allows to make multiple changes on a scratchpad configuration and once you are done with your changes, you commit the candidate configuration in a single commit operation. I believe this is actually better than trying to create a large atomic edit-config transaction. (So make sure the netconf implementations you are looking at support the candidate capability.) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Wed Nov 16 03:44:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcIte-0002Ja-7z for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 03:44:02 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10003 for ; Wed, 16 Nov 2005 03:43:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcIoK-0003r5-7D for netconf-data@psg.com; Wed, 16 Nov 2005 08:38:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcIoH-0003qf-Jq for netconf@ops.ietf.org; Wed, 16 Nov 2005 08:38:29 +0000 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AA0B6131F for ; Wed, 16 Nov 2005 09:37:40 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 09:37:39 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 09:37:38 +0100 Message-ID: <437AEFD3.3020901@ericsson.com> Date: Wed, 16 Nov 2005 09:37:39 +0100 From: Balazs Lengyel User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Multiple commands in one RPC Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2005 08:37:38.0897 (UTC) FILETIME=[00745410:01C5EA89] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello All, It is not explicitly mentioned, but I believe the intention was that one RPC request must contain only one single netconf command. Is this true ? If yes it would be nice to see this in the standard. Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- 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 Wed Nov 16 04:26:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcJYS-0004qY-8E for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 04:26:12 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12268 for ; Wed, 16 Nov 2005 04:25:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcJS1-0006xO-Bi for netconf-data@psg.com; Wed, 16 Nov 2005 09:19:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcJS0-0006xC-58 for netconf@ops.ietf.org; Wed, 16 Nov 2005 09:19:32 +0000 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8C7731511; Wed, 16 Nov 2005 10:19:21 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Nov 2005 10:17:42 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Nov 2005 10:17:41 +0100 Message-ID: <437AF936.5010107@ericsson.com> Date: Wed, 16 Nov 2005 10:17:42 +0100 From: Balazs Lengyel User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de Cc: netconf@ops.ietf.org Subject: Re: Transaction support in Netconf References: <437AEAC3.90206@ericsson.com> <20051116083558.GA8755@boskop.local> In-Reply-To: <20051116083558.GA8755@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2005 09:17:41.0634 (UTC) FILETIME=[9898E620:01C5EA8E] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Juergen, Why do you think using a candidate configuration is better then edit-config ? pro for using candidate: - It is difficult to assemple big edit config commands con: - the managed node needs to keep a complete candidate configuration or calculate a delta between the running and the candidate, which might be quite an effort Any other arguments ? Balazs PS. If I have other questions shall I keep posting them to the newsgroup or only to you ? Juergen Schoenwaelder wrote: > On Wed, Nov 16, 2005 at 09:16:03AM +0100, Balazs Lengyel wrote: > >>Hello All, >>I am investigating transaction support in Netconf. One way to handle this >>is to use an edit-config operation with the test=test-then-set and >>error=rollback options. This however raises some questions as this >>functionality covers only a single RPC request: > > >>1) How big can an RPC request be ? Any limit ? > > > I think the protocol does not specify a limit. However, concrete > implementations may have specific limits (after all, memory is usually > not unlimited). > > >>2) If I have a big configuration tree is it allowed to modify to >>independent parts of the configuration tree in one RPC request >>(e.g. add a new interface and switch on and configure OSPF in on >>request) ? > > > I think the answer here is that this is specifically allowed. > > The other option to address your requirement is to use the candidate > capability. This allows to make multiple changes on a scratchpad > configuration and once you are done with your changes, you commit the > candidate configuration in a single commit operation. I believe this > is actually better than trying to create a large atomic edit-config > transaction. (So make sure the netconf implementations you are looking > at support the candidate capability.) > > /js > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager & AXD Operational Suite (AOS) OPM ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- 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 Wed Nov 16 04:30:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcJco-00060m-K6 for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 04:30:42 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12469 for ; Wed, 16 Nov 2005 04:30:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcJXE-0007KW-Mh for netconf-data@psg.com; Wed, 16 Nov 2005 09:24:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcJXD-0007KJ-TB for netconf@ops.ietf.org; Wed, 16 Nov 2005 09:24:56 +0000 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 575854F0018 for ; Wed, 16 Nov 2005 10:21:37 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 10:19:44 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 10:19:43 +0100 Message-ID: <437AF9B0.4050500@ericsson.com> Date: Wed, 16 Nov 2005 10:19:44 +0100 From: Balazs Lengyel User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Implementations Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2005 09:19:43.0786 (UTC) FILETIME=[E167D0A0:01C5EA8E] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Is there somewhere a list of existing or planned netconf implementations ? I currently know about the following: EnSuite - Extended Netconf SUITE (Yencap) http://madynes.loria.fr/ensuite/ Written in Python, freeware (?) Erlang implementation by small Swedish company Wipro - XML Based Device Management http://www.wipro.com/prodesign/reusableframeworks/ip/xml.htm written in Java NEC Europe Ltd Germany written in C Postech Korea written in C Balazs -- 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 Wed Nov 16 04:40:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcJmG-0008N9-Ew for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 04:40:28 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12875 for ; Wed, 16 Nov 2005 04:39:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcJi0-0008SZ-VI for netconf-data@psg.com; Wed, 16 Nov 2005 09:36:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcJhz-0008SE-PW for netconf@ops.ietf.org; Wed, 16 Nov 2005 09:36:04 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id ED4B44C137; Wed, 16 Nov 2005 10:36:02 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 01925-02; Wed, 16 Nov 2005 10:36:01 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 8F42D4C0C1; Wed, 16 Nov 2005 10:36:01 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 27E4D52B01A; Wed, 16 Nov 2005 10:35:58 +0100 (CET) Date: Wed, 16 Nov 2005 10:35:57 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Cc: netconf@ops.ietf.org Subject: Re: Transaction support in Netconf Message-ID: <20051116093557.GB8891@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Balazs Lengyel , netconf@ops.ietf.org References: <437AEAC3.90206@ericsson.com> <20051116083558.GA8755@boskop.local> <437AF936.5010107@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <437AF936.5010107@ericsson.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk On Wed, Nov 16, 2005 at 10:17:42AM +0100, Balazs Lengyel wrote: > Why do you think using a candidate configuration is better then edit-config > ? > pro for using candidate: > - It is difficult to assemple big edit config commands > con: > - the managed node needs to keep a complete candidate configuration or > calculate a delta between the running and the candidate, which might be > quite an effort If you modify the candidate configuration in multiple netconf operations, you can get early feedback if you try to do something that won't work. I believe this is useful. Smart implementations may want to try to find a least disruptive transition from the current running configuration to the desired new configuration. So calculating the delta on the device might actually be a feature as this decouples the transition logic from the manager's instruction how to change the configuration. In other words, even if you ship a large edit config, it might internally make sense to create a temporary candidate configuration which is then committed (and you then calculate a least disruptive transition plan). But note that I am talking "theory" here since I have not written my own netconf implementation. But if I were to do it, I would try to do things as outlined above. Perhaps others who have been working on implementations can say how they actually deal with this. > PS. If I have other questions shall I keep posting them to the > newsgroup or only to you? Personally, I think this mailing list is a good place as long as you have generic questions related to netconf that are potentially of interest to others as well. This list does not suffer from too much traffic as far as I can tell. But at the end, the chairs must decide which traffic is appropriate here on the list and I know that IETF WGs have different policies when it comes to the discussion of implementation details. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Wed Nov 16 04:59:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcK4j-00045U-Cb for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 04:59:33 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13932 for ; Wed, 16 Nov 2005 04:58:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcJyY-000AEt-QF for netconf-data@psg.com; Wed, 16 Nov 2005 09:53:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [203.91.193.32] (helo=wip-ec-wd.wipro.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EcJyT-000ACq-HS for netconf@ops.ietf.org; Wed, 16 Nov 2005 09:53:10 +0000 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 9BADD205E5 for ; Wed, 16 Nov 2005 15:09:34 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 7E58D205DC for ; Wed, 16 Nov 2005 15:09:34 +0530 (IST) Received: from blr-m2-msg.wipro.com ([10.201.50.80]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Nov 2005 15:22:28 +0530 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Implementations Date: Wed, 16 Nov 2005 15:22:06 +0530 Message-ID: Thread-Topic: Implementations Thread-Index: AcXqkHt+dFfp3CA2SQmHcOxBX/jOHQAAs5DQ From: To: , X-OriginalArrivalTime: 16 Nov 2005 09:52:28.0449 (UTC) FILETIME=[746F9910:01C5EA93] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Small Correction - Wipro's NETCONF Agent is written in C and NETCONF Manager is in Java regards Manendra -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel Sent: Wednesday, November 16, 2005 2:50 PM To: netconf@ops.ietf.org Subject: Implementations Is there somewhere a list of existing or planned netconf implementations ? I currently=20 know about the following: EnSuite - Extended Netconf SUITE (Yencap) http://madynes.loria.fr/ensuite/ Written in Python, freeware (?) Erlang implementation by small Swedish company Wipro - XML Based Device Management =09 http://www.wipro.com/prodesign/reusableframeworks/ip/xml.htm written in Java NEC Europe Ltd Germany written in C Postech Korea written in C Balazs -- 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 Wed Nov 16 05:05:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcKAi-00065a-4X for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 05:05:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14266 for ; Wed, 16 Nov 2005 05:05:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcK4w-000AxJ-Rw for netconf-data@psg.com; Wed, 16 Nov 2005 09:59:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcK4w-000Ax6-5P for netconf@ops.ietf.org; Wed, 16 Nov 2005 09:59:46 +0000 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C0C5D144E for ; Wed, 16 Nov 2005 10:59:44 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Nov 2005 10:59:02 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Nov 2005 10:59:02 +0100 Message-ID: <437B02E6.8040107@ericsson.com> Date: Wed, 16 Nov 2005 10:59:02 +0100 From: Balazs Lengyel User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Detailed locking Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2005 09:59:02.0405 (UTC) FILETIME=[5F408350:01C5EA94] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit What is the reason that we only allow locking of a complete datastore. Ericsson might need a more fine grained locking mechanism. E.g. If we have subscriber data and device configuration data in the same node one manager might be updating the subscriber data while the other migh be changing OSPF settings. It could work perfectly as the two areas are quite separate. However if you lock the whole configuration this is not possible. -- Balazs Lengyel Ericsson Hungary Ltd. -- 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 Wed Nov 16 05:33:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcKbr-0004Tw-Uv for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 05:33:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15716 for ; Wed, 16 Nov 2005 05:33:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcKTk-000DJ1-M7 for netconf-data@psg.com; Wed, 16 Nov 2005 10:25:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcKTj-000DIp-Uf for netconf@ops.ietf.org; Wed, 16 Nov 2005 10:25:24 +0000 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DC9B81439 for ; Wed, 16 Nov 2005 11:23:49 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 11:21:45 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 11:21:45 +0100 Message-ID: <437B083A.9080204@ericsson.com> Date: Wed, 16 Nov 2005 11:21:46 +0100 From: Balazs Lengyel User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Multiple candidate datstores Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2005 10:21:45.0864 (UTC) FILETIME=[8BEFD880:01C5EA97] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 1) Is it allowed to have multiple candidate data-stores or just one ? 2) How do we address each ? 3) Can we indicate in the commit operation which datastrore do we want to commit ? regards -- Balazs Lengyel Ericsson Hungary Ltd. -- 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 Wed Nov 16 05:34:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcKcu-00050i-Un for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 05:34:52 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15759 for ; Wed, 16 Nov 2005 05:34:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcKZ4-000DhF-VE for netconf-data@psg.com; Wed, 16 Nov 2005 10:30:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [84.14.106.33] (helo=proxy.6wind.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcKZ2-000Dgs-1R for netconf@ops.ietf.org; Wed, 16 Nov 2005 10:30:52 +0000 Received: from [10.16.0.190] (unknown [10.16.0.190]) by proxy.6wind.com (Postfix) with ESMTP id 22B24525F8A; Wed, 16 Nov 2005 11:30:49 +0100 (CET) Message-ID: <437B0A58.3050907@6wind.com> Date: Wed, 16 Nov 2005 11:30:48 +0100 From: Damien Routier User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: Implementations References: <437AF9B0.4050500@ericsson.com> In-Reply-To: <437AF9B0.4050500@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, Let's add: 6WIND - XMS (eXtensible Management System) http://www.6wind.com written in C Best regards, Damien Routier > Is there somewhere a list of existing or planned netconf > implementations ? I currently know about the following: > > EnSuite - Extended Netconf SUITE (Yencap) > http://madynes.loria.fr/ensuite/ > Written in Python, freeware (?) > > Erlang implementation by small Swedish company > > Wipro - XML Based Device Management > http://www.wipro.com/prodesign/reusableframeworks/ip/xml.htm > written in Java > > NEC Europe Ltd Germany > written in C > > Postech Korea > written in C > > Balazs > > -- > 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 Wed Nov 16 05:47:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcKpS-0007uu-Nn for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 05:47:50 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16295 for ; Wed, 16 Nov 2005 05:47:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcKlR-000EgC-0Z for netconf-data@psg.com; Wed, 16 Nov 2005 10:43:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [152.81.1.70] (helo=macker.loria.fr) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcKlQ-000Eg1-3F for netconf@ops.ietf.org; Wed, 16 Nov 2005 10:43:40 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 25E2054BFD for ; Wed, 16 Nov 2005 11:43:39 +0100 (CET) X-Amavix: Anti-virus check done by ClamAV X-Amavix: Scanned by Amavix Received: from [152.81.8.136] (sydney.loria.fr [152.81.8.136]) by macker.loria.fr (Postfix) with ESMTP id 45F2354BFD for ; Wed, 16 Nov 2005 11:43:38 +0100 (CET) Message-ID: <437B0DBA.1010503@loria.fr> Date: Wed, 16 Nov 2005 11:45:14 +0100 From: Vincent Cridlig User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: netconf@ops.ietf.org Subject: Re: Implementations References: <437AF9B0.4050500@ericsson.com> In-Reply-To: <437AF9B0.4050500@ericsson.com> Content-Type: multipart/mixed; boundary="------------020905080501020508020909" Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------020905080501020508020909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit EnSuite is under LGPL. Vincent CRIDLIG Balazs Lengyel wrote: > Is there somewhere a list of existing or planned netconf > implementations ? I currently know about the following: > > EnSuite - Extended Netconf SUITE (Yencap) > http://madynes.loria.fr/ensuite/ > Written in Python, freeware (?) > > Erlang implementation by small Swedish company > > Wipro - XML Based Device Management > http://www.wipro.com/prodesign/reusableframeworks/ip/xml.htm > written in Java > > NEC Europe Ltd Germany > written in C > > Postech Korea > written in C > > Balazs > > -- > 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: --------------020905080501020508020909 Content-Type: text/x-vcard; charset=utf-8; name="vincent.cridlig.vcf" Content-Disposition: attachment; filename="vincent.cridlig.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Vincent Cridlig n:Cridlig;Vincent org:LORIA - INRIA Lorraine;Madynes adr:;;;Nancy;;;France email;internet:cridligv@loria.fr title:PhD Student tel;work:+33 (0)3 83 59 20 48 url:http://www.loria.fr/~cridligv version:2.1 end:vcard --------------020905080501020508020909-- -- 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 Wed Nov 16 05:50:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcKsC-0000bZ-HH for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 05:50:40 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16443 for ; Wed, 16 Nov 2005 05:50:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcKoR-000Evi-Ft for netconf-data@psg.com; Wed, 16 Nov 2005 10:46:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcKoO-000EvR-72 for netconf@ops.ietf.org; Wed, 16 Nov 2005 10:46:44 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 394044C1E4; Wed, 16 Nov 2005 11:46:43 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 08613-10; Wed, 16 Nov 2005 11:46:41 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id EDF6C4C153; Wed, 16 Nov 2005 11:46:41 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id C79C752B115; Wed, 16 Nov 2005 11:46:39 +0100 (CET) Date: Wed, 16 Nov 2005 11:46:39 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Cc: netconf@ops.ietf.org Subject: Re: Detailed locking Message-ID: <20051116104639.GB9098@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Balazs Lengyel , netconf@ops.ietf.org References: <437B02E6.8040107@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <437B02E6.8040107@ericsson.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk On Wed, Nov 16, 2005 at 10:59:02AM +0100, Balazs Lengyel wrote: > What is the reason that we only allow locking of a complete datastore. > > Ericsson might need a more fine grained locking mechanism. E.g. If we have > subscriber data and device configuration data in the same node one manager > might be updating the subscriber data while the other migh be changing OSPF > settings. It could work perfectly as the two areas are quite separate. > However if you lock the whole configuration this is not possible. The WG had a long discussion on the granularity of locking and finally ended up supporting only per datastore locks for netconf 1.0 in order to get netconf out of the door. I think people are encouraged to experiment with more granular locking schemes and can propose their solutions for incorporation into future netconf versions. If you want to see the details, see the meeting minutes and the mailing list archives. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Wed Nov 16 07:48:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcMiO-0001ff-RH for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 07:48:40 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22427 for ; Wed, 16 Nov 2005 07:48:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcMYw-000Myw-4F for netconf-data@psg.com; Wed, 16 Nov 2005 12:38:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.97] (helo=swip.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcMYq-000Myi-UV for netconf@ops.ietf.org; Wed, 16 Nov 2005 12:38:49 +0000 X-T2-Posting-ID: P5HZhTV1iTSvFccgWTR5dA== Received: from [213.100.166.180] (HELO localhost) by mailfe04.swip.net (CommuniGate Pro SMTP 5.0.1) with ESMTP id 13490959; Wed, 16 Nov 2005 13:38:46 +0100 Date: Wed, 16 Nov 2005 13:38:42 +0100 (CET) Message-Id: <20051116.133842.70211913.mbj@tail-f.com> To: balazs.lengyel@ericsson.com Cc: netconf@ops.ietf.org Subject: Re: Implementations From: Martin Bjorklund In-Reply-To: <437AF9B0.4050500@ericsson.com> References: <437AF9B0.4050500@ericsson.com> X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.3 / 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 Content-Transfer-Encoding: 7bit We have an extensible NETCONF agent implementation with C-APIs, see http://www.tail-f.com. /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 Wed Nov 16 07:59:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcMsq-0003nK-TF for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 07:59:28 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22992 for ; Wed, 16 Nov 2005 07:58:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcMkc-000Not-Cw for netconf-data@psg.com; Wed, 16 Nov 2005 12:50:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.1] (helo=swip.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcMkb-000Noh-La for netconf@ops.ietf.org; Wed, 16 Nov 2005 12:50:57 +0000 X-T2-Posting-ID: P5HZhTV1iTSvFccgWTR5dA== Received: from [213.100.166.180] (HELO localhost) by mailfe01.swip.net (CommuniGate Pro SMTP 5.0.1) with ESMTP id 17800739; Wed, 16 Nov 2005 13:50:56 +0100 Date: Wed, 16 Nov 2005 13:50:52 +0100 (CET) Message-Id: <20051116.135052.28402703.mbj@tail-f.com> To: j.schoenwaelder@iu-bremen.de Cc: balazs.lengyel@ericsson.com, netconf@ops.ietf.org Subject: Re: Transaction support in Netconf From: Martin Bjorklund In-Reply-To: <20051116093557.GB8891@boskop.local> References: <20051116083558.GA8755@boskop.local> <437AF936.5010107@ericsson.com> <20051116093557.GB8891@boskop.local> X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.3 / 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 Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > Smart implementations may want to try to find a least disruptive > transition from the current running configuration to the desired new > configuration. So calculating the delta on the device might actually > be a feature as this decouples the transition logic from the manager's > instruction how to change the configuration. In other words, even if > you ship a large edit config, it might internally make sense to create > a temporary candidate configuration which is then committed (and you > then calculate a least disruptive transition plan). > > But note that I am talking "theory" here since I have not written my > own netconf implementation. But if I were to do it, I would try to do > things as outlined above. Perhaps others who have been working on > implementations can say how they actually deal with this. We handle this in the way you describe, both for edit-config and copy-config. But I guess it's better to discuss details off-line. /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 Wed Nov 16 08:00:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcMtY-0003xy-3s for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 08:00:12 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23058 for ; Wed, 16 Nov 2005 07:59:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcMpl-000O9j-SG for netconf-data@psg.com; Wed, 16 Nov 2005 12:56:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.97] (helo=swip.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcMpj-000O9V-DH for netconf@ops.ietf.org; Wed, 16 Nov 2005 12:56:15 +0000 X-T2-Posting-ID: P5HZhTV1iTSvFccgWTR5dA== Received: from [213.100.166.180] (HELO localhost) by mailfe04.swip.net (CommuniGate Pro SMTP 5.0.1) with ESMTP id 13506760; Wed, 16 Nov 2005 13:56:14 +0100 Date: Wed, 16 Nov 2005 13:56:10 +0100 (CET) Message-Id: <20051116.135610.15254355.mbj@tail-f.com> To: balazs.lengyel@ericsson.com Cc: netconf@ops.ietf.org Subject: Re: Multiple candidate datstores From: Martin Bjorklund In-Reply-To: <437B083A.9080204@ericsson.com> References: <437B083A.9080204@ericsson.com> X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.3 / 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 Content-Transfer-Encoding: 7bit Balazs Lengyel wrote: > 1) Is it allowed to have multiple candidate data-stores or just one ? > 2) How do we address each ? > 3) Can we indicate in the commit operation which datastrore do we want to commit ? In the specification there's just a single candidate, and it's name is 'candidate'. /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 Wed Nov 16 08:49:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcNfg-0006iI-H3 for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 08:49:56 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25776 for ; Wed, 16 Nov 2005 08:49:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcNXs-00016b-Vo for netconf-data@psg.com; Wed, 16 Nov 2005 13:41:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.127.202.56] (helo=sccrmhc12.comcast.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcNXp-00016D-OL for netconf@ops.ietf.org; Wed, 16 Nov 2005 13:41:49 +0000 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc12) with SMTP id <2005111613414801200298h1e>; Wed, 16 Nov 2005 13:41:48 +0000 Reply-To: From: "David B Harrington" To: "'Martin Bjorklund'" , Cc: , Subject: RE: Transaction support in Netconf Date: Wed, 16 Nov 2005 08:41:41 -0500 Message-ID: <013401c5eab3$7a6a7590$0300a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20051116.135052.28402703.mbj@tail-f.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXqrZYxlXQin0xWSgq7QVYErPltMgABbOJw Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I think it would be helpful to other implementors, and to protocol designers, to discuss lessons learned during implementation on the list. David Harrington dbharrington@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Martin Bjorklund > Sent: Wednesday, November 16, 2005 7:51 AM > To: j.schoenwaelder@iu-bremen.de > Cc: balazs.lengyel@ericsson.com; netconf@ops.ietf.org > Subject: Re: Transaction support in Netconf > > Juergen Schoenwaelder wrote: > > Smart implementations may want to try to find a least disruptive > > transition from the current running configuration to the desired new > > configuration. So calculating the delta on the device might actually > > be a feature as this decouples the transition logic from > the manager's > > instruction how to change the configuration. In other words, even if > > you ship a large edit config, it might internally make > sense to create > > a temporary candidate configuration which is then committed (and you > > then calculate a least disruptive transition plan). > > > > But note that I am talking "theory" here since I have not written my > > own netconf implementation. But if I were to do it, I would > try to do > > things as outlined above. Perhaps others who have been working on > > implementations can say how they actually deal with this. > > We handle this in the way you describe, both for edit-config and > copy-config. But I guess it's better to discuss details off-line. > > > /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: > -- 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 Wed Nov 16 11:33:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcQDZ-0004qW-M4 for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 11:33:05 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08194 for ; Wed, 16 Nov 2005 11:32:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcQ6A-000Bbv-CN for netconf-data@psg.com; Wed, 16 Nov 2005 16:25:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.52 (FreeBSD)) id 1EcQ68-000Bbg-Qy for netconf@ops.ietf.org; Wed, 16 Nov 2005 16:25:25 +0000 Received: (qmail 1826 invoked by uid 78); 16 Nov 2005 16:25:17 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.57 with SMTP; 16 Nov 2005 16:25:17 -0000 Message-ID: <437B5DA7.6060308@andybierman.com> Date: Wed, 16 Nov 2005 08:26:15 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: Balazs Lengyel , netconf@ops.ietf.org Subject: Re: Transaction support in Netconf References: <437AEAC3.90206@ericsson.com> <20051116083558.GA8755@boskop.local> <437AF936.5010107@ericsson.com> <20051116093557.GB8891@boskop.local> In-Reply-To: <20051116093557.GB8891@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: >On Wed, Nov 16, 2005 at 10:17:42AM +0100, Balazs Lengyel wrote: > > > >>Why do you think using a candidate configuration is better then edit-config >>? >>pro for using candidate: >>- It is difficult to assemple big edit config commands >>con: >>- the managed node needs to keep a complete candidate configuration or >>calculate a delta between the running and the candidate, which might be >>quite an effort >> >> > >If you modify the candidate configuration in multiple netconf >operations, you can get early feedback if you try to do something >that won't work. I believe this is useful. > >Smart implementations may want to try to find a least disruptive >transition from the current running configuration to the desired new >configuration. So calculating the delta on the device might actually >be a feature as this decouples the transition logic from the manager's >instruction how to change the configuration. In other words, even if >you ship a large edit config, it might internally make sense to create >a temporary candidate configuration which is then committed (and you >then calculate a least disruptive transition plan). > >But note that I am talking "theory" here since I have not written my >own netconf implementation. But if I were to do it, I would try to do >things as outlined above. Perhaps others who have been working on >implementations can say how they actually deal with this. > > The correct implementation of the model is a fundamental design choice in the managed system. By definition, means the capability to edit potentially the entire device configuration 'offline' (in the candidate config) is built into the system. The implementation of the config update (apply whole document, edit-list, etc.) inside the agent is outside the scope of the protocol. It's either totally up to the agent instrumentation or handled in the engine, or some combination of both. The automatic processing of arbitrary data structures is non-trivial, to say the least. Traditional XML document processing tools may not fare so well in large embedded devices. > > >>PS. If I have other questions shall I keep posting them to the >>newsgroup or only to you? >> >> > >Personally, I think this mailing list is a good place as long as you >have generic questions related to netconf that are potentially of >interest to others as well. This list does not suffer from too much >traffic as far as I can tell. But at the end, the chairs must decide >which traffic is appropriate here on the list and I know that IETF >WGs have different policies when it comes to the discussion of >implementation details. > > Really, policies? Not surprising these days. I should look into it. ;-) I think it's totally up to you if you want to post or reply regarding implementation details. So far, all of the emails have been appropriate, some questions obvious from reading the drafts, but some that have really made us think about specific details in the drafts. The entire point of these RFCs is to convey information to people about how to implement and use NETCONF. There are people implementing it, and their immediate feedback helps us debug the drafts that much faster. However, questions about code (like how to get cyrus-sasl working on Fedora-4) should NOT be sent to this list. Just questions related to the NETCONF protocol. I talked to Simon and various IESG members about setting up another mailing list on ietf.org for implementation discussion. This was done for diffserv I believe. Maybe now we should try to set that up. >/js > > > 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 Wed Nov 16 11:37:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcQHs-0006O2-1z for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 11:37:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08479 for ; Wed, 16 Nov 2005 11:36:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcQC3-000Bx1-2N for netconf-data@psg.com; Wed, 16 Nov 2005 16:31:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcQC1-000Bwk-Kl for netconf@ops.ietf.org; Wed, 16 Nov 2005 16:31:29 +0000 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 288FD4F0006 for ; Wed, 16 Nov 2005 17:29:19 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 17:28:30 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 17:28:29 +0100 Message-ID: <437B5E2D.9020504@ericsson.com> Date: Wed, 16 Nov 2005 17:28:29 +0100 From: Balazs Lengyel User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: One request multiple replies Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2005 16:28:30.0048 (UTC) FILETIME=[C773DE00:01C5EACA] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Is it allowed for a netconf device to issue multiple replies for one netconf request ? We have operations in our nodes that may take 10 minutes to execute. I order the execution but I don't want to sit there waiting for a reply for 10 minutes. I also don't want to block the netconf session for 10 minutes. How do you solve this situation ? I was thinking about sending a provisional reply back immediately e.g. operation started and then sending a final reply e.g. operation finished when the thing really is executed. Another solution could be to open a separate netconf session for the long running operation. Any ideas ? regards Balazs P.S. Thanks for all the help today. -- Balazs Lengyel Ericsson Hungary Ltd. -- 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 Wed Nov 16 12:01:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcQfL-0005AW-FO for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 12:01:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10015 for ; Wed, 16 Nov 2005 12:01:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcQVM-000DAX-Rt for netconf-data@psg.com; Wed, 16 Nov 2005 16:51:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.52 (FreeBSD)) id 1EcQVL-000DAL-U7 for netconf@ops.ietf.org; Wed, 16 Nov 2005 16:51:28 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id jAGGpQ022679; Wed, 16 Nov 2005 08:51:26 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jAGGpKp93350; Wed, 16 Nov 2005 08:51:20 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id jAGGuZYE067154; Wed, 16 Nov 2005 11:56:37 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200511161656.jAGGuZYE067154@idle.juniper.net> To: Balazs Lengyel cc: netconf@ops.ietf.org Subject: Re: One request multiple replies In-Reply-To: Your message of "Wed, 16 Nov 2005 17:28:29 +0100." <437B5E2D.9020504@ericsson.com> Date: Wed, 16 Nov 2005 11:56:35 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Balazs Lengyel writes: >Is it allowed for a netconf device to issue multiple replies for one netconf request ? No, it's a one-to-one relationship between request and reply. >We have operations in our nodes that may take 10 minutes to execute. I order the >execution but I don't want to sit there waiting for a reply for 10 minutes. I also don't >want to block the netconf session for 10 minutes. How do you solve this situation ? Two schemes: simplest is to just open a second connection. Gives you a completely independent communication path. The other option is to return some token which future RPCs can poll for status on the operation. Thanks, Phil -- 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 Wed Nov 16 12:03:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcQhP-0005N9-5z for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 12:03:55 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10109 for ; Wed, 16 Nov 2005 12:03:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcQa3-000DS3-3Y for netconf-data@psg.com; Wed, 16 Nov 2005 16:56:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [193.145.240.2] (helo=correo.tid.es) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcQa2-000DRq-0J for netconf@ops.ietf.org; Wed, 16 Nov 2005 16:56:18 +0000 Received: from tid (filvit [192.168.48.202]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IQ200E1Y4ECOF@tid.hi.inet> for netconf@ops.ietf.org; Wed, 16 Nov 2005 17:56:36 +0100 (MET) Received: from RAISTLIN (RAISTLIN.hi.inet [10.95.46.27]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with SMTP id <0IQ200E1T4ECOF@tid.hi.inet> for netconf@ops.ietf.org; Wed, 16 Nov 2005 17:56:36 +0100 (MET) Date: Wed, 16 Nov 2005 17:56:15 +0100 From: Miguel Angel Fernandez Gutierrez Subject: Re: One request multiple replies To: Balazs Lengyel , netconf@ops.ietf.org Message-id: <0f4c01c5eace$a85f2f20$1b2e5f0a@hi.inet> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; reply-type=response; charset=iso-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:16 M:2 S:5 R:5 X-imss-settings: Baseline:2 C:1 M:1 S:2 R:1 (0.0100 0.0100) References: <437B5E2D.9020504@ericsson.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT > Is it allowed for a netconf device to issue multiple replies for one > netconf request ? > > We have operations in our nodes that may take 10 minutes to execute. I > order the execution but I don't want to sit there waiting for a reply for > 10 minutes. I also don't want to block the netconf session for 10 minutes. > How do you solve this situation ? > > I was thinking about sending a provisional reply back immediately e.g. > operation started and then sending a final reply e.g. operation finished > when the thing really is executed. > > Another solution could be to open a separate netconf session for the long > running operation. The problem with this is approach is that support for multiple concurrent netconf sessions is not a MUST but only a SHOULD, if I'm not mistaken. So you cannot rely on this idea as a general solution. I think you can get only one reply to a request. Perhaps the reply could be an immediate "operation started", and then you can issue subsequent requests for processing progress, that could be also immediately answered like "operation in process (X% complete)" and, finally, "operation complete" (with success or error). Sorry if this sounds silly. I'm only a couple of weeks worth on NetConf yet. --- Miguel Angel Fernandez Telefonica I+D - Spain -- 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 Wed Nov 16 14:50:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTIz-0005FC-Gk for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 14:50:53 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20077 for ; Wed, 16 Nov 2005 14:50:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcTC3-000MdD-CV for netconf-data@psg.com; Wed, 16 Nov 2005 19:43:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [207.69.195.66] (helo=pop-canoe.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcTC0-000Mcz-0p for netconf@ops.ietf.org; Wed, 16 Nov 2005 19:43:42 +0000 Received: from h-64-105-34-178.snvacaid.dynamic.covad.net ([64.105.34.178] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EcTBz-0001np-00 for netconf@ops.ietf.org; Wed, 16 Nov 2005 14:43:39 -0500 Message-ID: <000001c5eae6$a74323e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <437AF9B0.4050500@ericsson.com> <20051116.133842.70211913.mbj@tail-f.com> Subject: Re: Implementations Date: Wed, 16 Nov 2005 11:28:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi - Is it too early for someone to put together a web site that consolidates this information, perhaps in a manner similar to http://www.ibr.cs.tu-bs.de/projects/snmpv3/ ? Randy -- 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 Wed Nov 16 15:22:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTnD-0004Wu-84 for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 15:22:07 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21639 for ; Wed, 16 Nov 2005 15:21:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcThp-000OTH-I7 for netconf-data@psg.com; Wed, 16 Nov 2005 20:16:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcTho-000OT2-9V for netconf@ops.ietf.org; Wed, 16 Nov 2005 20:16:32 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jAGKGRm16599 for ; Wed, 16 Nov 2005 15:16:27 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Notes from Netconf Event Editing Session Date: Wed, 16 Nov 2005 15:16:27 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405C06E36@zcarhxm2.corp.nortel.com> Thread-Topic: Notes from Netconf Event Editing Session Thread-Index: AcXq6p+eDIZk9P9RRnisygKICwISnQ== From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi The session on November 8th was attended by 11 people from 8 organizations. Most of the people had read the draft prior to the session. =09 http://www.ietf.org/internet-drafts/draft-chisholm-netconf-event-01.txt Here are my notes. 1. There were some concerns raised about the filtering mechanisms defined within the draft and how they would actually work with event messages. Note that these are the filtering methods originally defined in base Netconf. Hector agreed to write up some examples to demonstrate how they would work as well as to test their usability. 2. It was noted that the definition of event class is circular and in general needs work. Sharon agreed to try to clean this section up. Clarification should also be added that it is expected that the contents of the messages are expected to differ for each event class. 3. There was discussion on subscription ID and why more than one subscription on a single connection was allowed. The answer is that there is no compelling reason to not allow more than one subscription per connection and there are some benefits to allowing it. People who want to keep things simple can choose to only have a single subscription per connections. Those who would like more than one to support use cases such as having two different sets of filters applied with the information handled differently on the receiving end or, if supported, a replay function and a real-time event stream can do so. This should probably be discussed more within the document itself. The subscription ID enables multiple subscriptions per connection and also allows someone to monitor a subscription from another connection. 4. Discussion about session IDs and more than one beep channel is needed. 5. Note that sequence numbers detect lost events on a still-up connection. If you loose the connection, all bets are off and you should assume that you lost information. Management applications typically assume this anyways and tend towards re-discovery when the connection/communication is resumed. 6. The optionality of various bits of content in the appendix needs to be validated. Hector agreed to do this. 7. In section 2.1.1, it should be noted that event class, filter and named profile are independent parameters. This means they are not mutually exclusive, but rather that they have an accumulative effect on the content of the subscription. 8. In section 2.2.1, discussion needs to be added around the behaviour of sequence numbers after wrapping and reboot. This is not persistent across reboots. 9. Section 2.3, which discusses changing a subscription, needs an example. There was discussion about alterative syntax for modifying subscription that would be subtractive rather than fully specifying the new subscription, but this approach seemed to have its own challenges. After the example is given with the current approach, we can test the current syntax. 10. We need the read-only schema for querying subscription properties as identified in section 3.2. Sharon to write this up. 12. Currently the draft discusses named profiles as something dynamic. When they change, the subscription gets updated. After much discussion, it was decided it might make more sense to make them static. If they are changed, this has no affect on the event subscription until an explicit modify subscription command is sent. This was the preferred approach in the room. 13. The title of section 3.4.2 should be changed to 'Filtering'. Better yet, we may want to just roll section 3.4.1 and 3.4.2 to be in the appropriate places in section 2. It is a bit confusing trying to figure out where to define things - within the netconf template or within a paragraph somewhere. 14. In section 3.4.2, better explain that this filtering is specified as a parameter to the command and is not defined independent (and is not persistent beyond the subscription) compared to named profiles. 15. In section 3.5, the order that the event classes are explained should be aligned with the order in which they are listed. 16. In section 3.5, it should be explained that heartbeats do have sequence numbers, but that the messages themselves should not be included in any message logging that the system may choose to do. 17. In section 3.5, discussion about whether event classes are an IANA managed resources should be included. They probably are. 18. In section 3.5, there was discussion around the difference between fault and alarm. If there are not non-alarm fault events then fault might be a better term to use. Sharon agreed to look into this a bit more. There was also discussion about whether a threshold crossing was a fault event or a class onto its own. 19. In section A.3, it was questioned whether we really needed sysUptime. It was noted that if it is there, both it and event generation time need to be separately defined fields, even if they end up forming parts of the same type. The second paragraph should refer to RFC3418 and not 1907. 20. In section A.10, there is not discussion about what clear means. If clear were to be defined, it might handle the issue raised in the second paragraph about the ambiguity in the RMON model. 21. For sections B.2.5 through B.2.8, there needs to be an explanation of how the CLI text option would work. Hector agreed to provide this. 22. In section C.2.3, it should be clarified that the intension is to explore a command that would allow you to indicate that you want information to hang around after the connection is terminated. It was noted that there were resource considerations around this (including orphaned resources) and potential impacts on sequence numbers. 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 Wed Nov 16 16:57:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcVH7-0007Bq-NS for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 16:57:05 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02485 for ; Wed, 16 Nov 2005 16:56:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EcV58-0004z4-Vw for netconf-data@psg.com; Wed, 16 Nov 2005 21:44:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.54 (FreeBSD)) id 1EcV55-0004yn-JU for netconf@ops.ietf.org; Wed, 16 Nov 2005 21:44:40 +0000 Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.13.4+Sun/8.13.4) with ESMTP id jAGLiZPk007063 (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO); Wed, 16 Nov 2005 22:44:36 +0100 (CET) Received: (from leinen@localhost) by diotima.switch.ch (8.13.4+Sun/8.13.4/Submit) id jAGLiZec007062; Wed, 16 Nov 2005 22:44:35 +0100 (CET) To: "Randy Presuhn" Cc: Subject: Re: Implementations 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` From: Simon Leinen In-Reply-To: <000001c5eae6$a74323e0$7f1afea9@oemcomputer> (Randy Presuhn's message of "Wed, 16 Nov 2005 11:28:38 -0800") References: <437AF9B0.4050500@ericsson.com> <20051116.133842.70211913.mbj@tail-f.com> <000001c5eae6$a74323e0$7f1afea9@oemcomputer> Date: Wed, 16 Nov 2005 22:44:34 +0100 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netconf@ops.ietf.org Precedence: bulk Randy Presuhn writes: > Is it too early for someone to put together a web site that > consolidates this information, perhaps in a manner similar > to http://www.ibr.cs.tu-bs.de/projects/snmpv3/ ? Not the same level of detail, but I just added pointers to these implementations to http://www.ops.ietf.org/netconf/#implementations Please don't hesitate to contact me if you have any additions. Regards, -- Simon. -- 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 Wed Nov 16 21:37:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcZe8-0006VO-Iw for netconf-archive@megatron.ietf.org; Wed, 16 Nov 2005 21:37:08 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20148 for ; Wed, 16 Nov 2005 21:36:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EcZUx-000LOi-GQ for netconf-data@psg.com; Thu, 17 Nov 2005 02:27:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1EcZUu-000LOP-Ku for netconf@ops.ietf.org; Thu, 17 Nov 2005 02:27:37 +0000 Received: (qmail 10436 invoked by uid 78); 17 Nov 2005 02:27:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.55 with SMTP; 17 Nov 2005 02:27:35 -0000 Message-ID: <437BEA88.4030904@andybierman.com> Date: Wed, 16 Nov 2005 18:27:20 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: notification charter proposal Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Please comment on the following charter text before it goes to the ADs for approval. thanks, Andy and Simon ============================================================ NETCONF WG Charter Clarification proposal: The original NETCONF WG charter contains the following line item, describing the characteristics that the protocol should have: - Provides support for asynchronous notifications This support was removed from the protocol for several reasons, including: - Removal of multiple channels (or connections) per session - Inconsistent notification support capabilities for each application mapping - Lack of a configurable notification type selection (filtering) mechanism - Lack of consensus on feature importance - Lack of time to reach consensus on all these issues Some time has passed, and there is now WG consensus to finish this work item, however the single line in the original charter needs to be expanded and this work scoped in much more detail. The NETCONF Notification work shall consist of the following: - Specify the message (capability exchange) details to support notifications. - Specify the application mapping details to support notifications. - Specify the protocol syntax and semantics of a notification message. - Specify a mechanism for controlling the delivery (turn on/off) of notifications during a session. - Specify a mechanism for selectively receiving a configurable subset of all possible notification types. An individual submission Internet Draft has been proposed to the WG as the starting point for this work. Unless there are any strong objections or alternate proposals, the WG shall adopt the document identified as 'draft-chisholm-netconf-event-01.txt' as the starting point for this work. Goals and Milestones Dec 05 Update charter Jan 06 Submit first version of NETCONF Notifications document Sep 06 Begin WGLC of NETCONF Notifications document Dec 06 Submit final version of NETCONF Notifications document to IESG for consideration -- 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 Nov 17 05:34:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ech67-0000gB-Cj for netconf-archive@megatron.ietf.org; Thu, 17 Nov 2005 05:34:31 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12432 for ; Thu, 17 Nov 2005 05:33:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ecgwd-00002D-Tn for netconf-data@psg.com; Thu, 17 Nov 2005 10:24:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ecgwc-000020-Nl for netconf@ops.ietf.org; Thu, 17 Nov 2005 10:24:42 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 8643F4BDD1; Thu, 17 Nov 2005 11:24:41 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 25777-10; Thu, 17 Nov 2005 11:24:40 +0100 (CET) Received: from boskop.local (unknown [10.71.237.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 459924BDA0; Thu, 17 Nov 2005 11:24:40 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 31F2852BB98; Thu, 17 Nov 2005 11:24:36 +0100 (CET) Date: Thu, 17 Nov 2005 11:24:36 +0100 From: Juergen Schoenwaelder To: Andy Bierman Cc: netconf@ops.ietf.org Subject: Re: Transaction support in Netconf Message-ID: <20051117102436.GA10831@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , netconf@ops.ietf.org References: <437AEAC3.90206@ericsson.com> <20051116083558.GA8755@boskop.local> <437AF936.5010107@ericsson.com> <20051116093557.GB8891@boskop.local> <437B5DA7.6060308@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <437B5DA7.6060308@andybierman.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk On Wed, Nov 16, 2005 at 08:26:15AM -0800, Andy Bierman wrote: > I talked to Simon and various IESG members about setting up another > mailing list on ietf.org for implementation discussion. This was > done for diffserv I believe. Maybe now we should try to set that > up. Since you mention it, diffserv was the specific case I had in mind where implementation discussions were pretty much discouraged on the diffserv mailing list. Personally, I did not like this approach very much since I believe implementation and even early deployment experience is extremely useful (and this list can sustain some more traffic I would say). So I would prefer to _not_ follow the diffserv model. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Nov 17 07:21:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecilh-00027z-Uk for netconf-archive@megatron.ietf.org; Thu, 17 Nov 2005 07:21:34 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18671 for ; Thu, 17 Nov 2005 07:20:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EcieU-0006QK-Iq for netconf-data@psg.com; Thu, 17 Nov 2005 12:14:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EcieT-0006Q7-RJ for netconf@ops.ietf.org; Thu, 17 Nov 2005 12:14:05 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jAHCE0Cq003792; Thu, 17 Nov 2005 06:14:00 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 17 Nov 2005 13:13:59 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550897EEA1@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: j.schoenwaelder@iu-bremen.de, Andy Bierman Cc: netconf@ops.ietf.org Subject: RE: Transaction support in Netconf Date: Thu, 17 Nov 2005 13:13:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-netconf@ops.ietf.org Precedence: bulk I personally would prefer we have implementation discussion on the netconf WG list itself. At least for now. Later on, we can decide to move it. But it is up to the WG chairs and WG to decide. Bert > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Juergen Schoenwaelder > Sent: Thursday, November 17, 2005 11:25 > To: Andy Bierman > Cc: netconf@ops.ietf.org > Subject: Re: Transaction support in Netconf > > > On Wed, Nov 16, 2005 at 08:26:15AM -0800, Andy Bierman wrote: > > > I talked to Simon and various IESG members about setting up another > > mailing list on ietf.org for implementation discussion. This was > > done for diffserv I believe. Maybe now we should try to set that > > up. > > Since you mention it, diffserv was the specific case I had in mind > where implementation discussions were pretty much discouraged on the > diffserv mailing list. Personally, I did not like this approach very > much since I believe implementation and even early deployment > experience is extremely useful (and this list can sustain some more > traffic I would say). So I would prefer to _not_ follow the diffserv > model. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > > -- > 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 Thu Nov 17 12:20:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcnRP-0008DT-M5 for netconf-archive@megatron.ietf.org; Thu, 17 Nov 2005 12:20:56 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07811 for ; Thu, 17 Nov 2005 12:20:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EcnIS-0000wU-09 for netconf-data@psg.com; Thu, 17 Nov 2005 17:11:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1EcnIO-0000wG-1L for netconf@ops.ietf.org; Thu, 17 Nov 2005 17:11:36 +0000 Received: (qmail 23607 invoked by uid 78); 17 Nov 2005 17:11:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.60 with SMTP; 17 Nov 2005 17:11:24 -0000 Message-ID: <437CB9B9.3070404@andybierman.com> Date: Thu, 17 Nov 2005 09:11:21 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: j.schoenwaelder@iu-bremen.de, netconf@ops.ietf.org Subject: Re: Transaction support in Netconf References: <7D5D48D2CAA3D84C813F5B154F43B1550897EEA1@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550897EEA1@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Wijnen, Bert (Bert) wrote: > >I personally would prefer we have implementation discussion on >the netconf WG list itself. At least for now. Later on, we can >decide to move it. > > yes -- that's fine with me. I don't think it's a problem either. I was actually thinking another list is a feature, because the threads could go into more implementation detail without worrying about cluttering the WG list. But that is more appropriate for an open-source project mailing list, so never mind. Andy >But it is up to the WG chairs and WG to decide. > >Bert > > >>-----Original Message----- >>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On >>Behalf Of Juergen Schoenwaelder >>Sent: Thursday, November 17, 2005 11:25 >>To: Andy Bierman >>Cc: netconf@ops.ietf.org >>Subject: Re: Transaction support in Netconf >> >> >>On Wed, Nov 16, 2005 at 08:26:15AM -0800, Andy Bierman wrote: >> >> >> >>>I talked to Simon and various IESG members about setting up another >>>mailing list on ietf.org for implementation discussion. This was >>>done for diffserv I believe. Maybe now we should try to set that >>>up. >>> >>> >>Since you mention it, diffserv was the specific case I had in mind >>where implementation discussions were pretty much discouraged on the >>diffserv mailing list. Personally, I did not like this approach very >>much since I believe implementation and even early deployment >>experience is extremely useful (and this list can sustain some more >>traffic I would say). So I would prefer to _not_ follow the diffserv >>model. >> >>/js >> >>-- >>Juergen Schoenwaelder International University Bremen >> P.O. Box 750 561, >>28725 Bremen, Germany >> >>-- >>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 Thu Nov 17 13:59:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecoyl-0004Oi-F1 for netconf-archive@megatron.ietf.org; Thu, 17 Nov 2005 13:59:27 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14149 for ; Thu, 17 Nov 2005 13:58:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EcosV-0007hG-9r for netconf-data@psg.com; Thu, 17 Nov 2005 18:52:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EcosU-0007h3-IT for netconf@ops.ietf.org; Thu, 17 Nov 2005 18:52:58 +0000 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by kremlin.juniper.net with ESMTP; 17 Nov 2005 10:52:59 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,343,1125903600"; d="scan'208"; a="511400450:sNHT22725240" Received: from photon.jnpr.net ([172.24.18.198]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Nov 2005 10:52:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Detailed locking Date: Thu, 17 Nov 2005 10:52:47 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D440D30C293@photon.jnpr.net> Thread-Topic: Detailed locking Thread-Index: AcXqlLkYX+gA8bs0T2S/NGfAeiueLwBEmYgw From: "Rob Enns" To: "Balazs Lengyel" , X-OriginalArrivalTime: 17 Nov 2005 18:52:57.0949 (UTC) FILETIME=[205658D0:01C5EBA8] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Fine grained locking was deferred from the 1.0 protocol spec, in the interest of simplicity. You're quite right about the limitations of the global lock, I'm sure fine grained locking will be high on the list of post 1.0 work items. Rob=20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel > Sent: Wednesday, November 16, 2005 1:59 AM > To: netconf@ops.ietf.org > Subject: Detailed locking >=20 > What is the reason that we only allow locking of a complete datastore. >=20 > Ericsson might need a more fine grained locking mechanism.=20 > E.g. If we have subscriber data=20 > and device configuration data in the same node one manager=20 > might be updating the=20 > subscriber data while the other migh be changing OSPF=20 > settings. It could work perfectly as=20 > the two areas are quite separate. However if you lock the=20 > whole configuration this is not=20 > possible. >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. >=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: From owner-netconf@ops.ietf.org Thu Nov 17 17:29:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcsFg-0005Ql-8V for netconf-archive@megatron.ietf.org; Thu, 17 Nov 2005 17:29:08 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00621 for ; Thu, 17 Nov 2005 17:28:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ecs6c-000KH8-FA for netconf-data@psg.com; Thu, 17 Nov 2005 22:19:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ecs6b-000KGr-Ck for netconf@ops.ietf.org; Thu, 17 Nov 2005 22:19:45 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jAHMJZo18579; Thu, 17 Nov 2005 17:19:35 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: notification charter proposal Date: Thu, 17 Nov 2005 17:17:56 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D072B3C62@zcarhxm0.corp.nortel.com> Thread-Topic: notification charter proposal Thread-Index: AcXrH+f6Esq65youTReSyt0aW04vLAAmmQsg From: "Glenn Waters" To: "Andy Bierman" , Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Great news! Good to see a charter proposal for notifications. Cheers, /gww=20 > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Andy Bierman > Sent: Wednesday, November 16, 2005 21:27 > To: netconf@ops.ietf.org > Subject: notification charter proposal >=20 > Hi, >=20 > Please comment on the following charter text before it goes to the > ADs for approval. >=20 > thanks, > Andy and Simon >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > NETCONF WG Charter Clarification proposal: >=20 > The original NETCONF WG charter contains the following line item, > describing the characteristics that the protocol should have: >=20 > - Provides support for asynchronous notifications >=20 > This support was removed from the protocol for several reasons, including: >=20 > - Removal of multiple channels (or connections) per session > - Inconsistent notification support capabilities for each application > mapping > - Lack of a configurable notification type selection (filtering) > mechanism > - Lack of consensus on feature importance > - Lack of time to reach consensus on all these issues >=20 > Some time has passed, and there is now WG consensus to finish this > work item, however the single line in the original charter needs to > be expanded and this work scoped in much more detail. >=20 > The NETCONF Notification work shall consist of the following: >=20 > - Specify the message (capability exchange) details to > support notifications. > - Specify the application mapping details to support notifications. > - Specify the protocol syntax and semantics of a notification message. > - Specify a mechanism for controlling the delivery (turn on/off) > of notifications during a session. > - Specify a mechanism for selectively receiving a configurable subset > of all > possible notification types. >=20 > An individual submission Internet Draft has been proposed to the WG > as the starting point for this work. Unless there are any strong > objections or alternate proposals, the WG shall adopt the document > identified as 'draft-chisholm-netconf-event-01.txt' as the starting > point for this work. >=20 > Goals and Milestones >=20 > Dec 05 Update charter > Jan 06 Submit first version of NETCONF Notifications document > Sep 06 Begin WGLC of NETCONF Notifications document > Dec 06 Submit final version of NETCONF Notifications document to > IESG for > consideration >=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: -- 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 Nov 21 10:34:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeDgj-0007gg-Nz for netconf-archive@megatron.ietf.org; Mon, 21 Nov 2005 10:34:37 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09091 for ; Mon, 21 Nov 2005 10:33:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeDSn-0001JP-HW for netconf-data@psg.com; Mon, 21 Nov 2005 15:20:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeDSm-0001JC-Ef for netconf@ops.ietf.org; Mon, 21 Nov 2005 15:20:12 +0000 Received: from pc6 (1Cust221.tnt4.lnd4.gbr.da.uu.net [62.188.133.221]) by blaster.systems.pipex.net (Postfix) with SMTP id C98F8E0000F2; Mon, 21 Nov 2005 15:20:02 +0000 (GMT) Message-ID: <03f901c5eea6$6c4b8e80$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Andy Bierman" , References: <437BEA88.4030904@andybierman.com> Subject: Re: notification charter proposal Date: Mon, 21 Nov 2005 15:02:44 +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 Content-Transfer-Encoding: 7bit Andy Notifications or events, or asynchronous messages? As Sharon says "an asynchronous message, sometimes referred to as a notification or event message" I get a slight sense of you and Sharon determinedly heading in different directions:-( Tom Petch ----- Original Message ----- From: "Andy Bierman" To: Sent: Thursday, November 17, 2005 3:27 AM Subject: notification charter proposal > Hi, > > Please comment on the following charter text before it goes to the > ADs for approval. > > thanks, > Andy and Simon > > ============================================================ > > NETCONF WG Charter Clarification proposal: > > The original NETCONF WG charter contains the following line item, > describing the characteristics that the protocol should have: > > - Provides support for asynchronous notifications > > This support was removed from the protocol for several reasons, including: > > - Removal of multiple channels (or connections) per session > - Inconsistent notification support capabilities for each application > mapping > - Lack of a configurable notification type selection (filtering) mechanism > - Lack of consensus on feature importance > - Lack of time to reach consensus on all these issues > > Some time has passed, and there is now WG consensus to finish this > work item, however the single line in the original charter needs to > be expanded and this work scoped in much more detail. > > The NETCONF Notification work shall consist of the following: > > - Specify the message (capability exchange) details to > support notifications. > - Specify the application mapping details to support notifications. > - Specify the protocol syntax and semantics of a notification message. > - Specify a mechanism for controlling the delivery (turn on/off) > of notifications during a session. > - Specify a mechanism for selectively receiving a configurable subset > of all > possible notification types. > > An individual submission Internet Draft has been proposed to the WG > as the starting point for this work. Unless there are any strong > objections or alternate proposals, the WG shall adopt the document > identified as 'draft-chisholm-netconf-event-01.txt' as the starting > point for this work. > > Goals and Milestones > > Dec 05 Update charter > Jan 06 Submit first version of NETCONF Notifications document > Sep 06 Begin WGLC of NETCONF Notifications document > Dec 06 Submit final version of NETCONF Notifications document to > IESG for > consideration > > > > > -- > 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 Nov 21 10:50:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeDwW-0002mP-OZ for netconf-archive@megatron.ietf.org; Mon, 21 Nov 2005 10:50:57 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10324 for ; Mon, 21 Nov 2005 10:50:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeDo7-0002u6-Gu for netconf-data@psg.com; Mon, 21 Nov 2005 15:42:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1EeDo6-0002tk-IY for netconf@ops.ietf.org; Mon, 21 Nov 2005 15:42:14 +0000 Received: (qmail 20295 invoked by uid 78); 21 Nov 2005 15:42:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.52 with SMTP; 21 Nov 2005 15:42:13 -0000 Message-ID: <4381EAD3.8000602@andybierman.com> Date: Mon, 21 Nov 2005 07:42:11 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Petch CC: netconf@ops.ietf.org Subject: Re: notification charter proposal References: <437BEA88.4030904@andybierman.com> <03f901c5eea6$6c4b8e80$0601a8c0@pc6> In-Reply-To: <03f901c5eea6$6c4b8e80$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tom Petch wrote: >Andy > >Notifications or events, or asynchronous messages? > >As Sharon says >"an asynchronous message, sometimes referred to as a > notification or event message" > >I get a slight sense of you and Sharon determinedly heading in different >directions:-( > > Notifications. I want to design features with a specific purpose. NETCONF is not a transport for arbitrary asynch messages. We will not have super-loose definitions of protocol elements, so that (for example) NETCONF notifications could be used to carry IPFIX reports or SW downloads or whatever. I think there is something in the draft called a "one-way RPC" that I really disagree with. Once you start down the slippery slope (e.g., declaring a notification can be a 4 billion byte octet stream) then all implementations get more difficult, even though hardly anyone wants this sort of "notification feature". >Tom Petch > > Andy >----- Original Message ----- >From: "Andy Bierman" >To: >Sent: Thursday, November 17, 2005 3:27 AM >Subject: notification charter proposal > > > > >>Hi, >> >>Please comment on the following charter text before it goes to the >>ADs for approval. >> >>thanks, >>Andy and Simon >> >>============================================================ >> >>NETCONF WG Charter Clarification proposal: >> >>The original NETCONF WG charter contains the following line item, >>describing the characteristics that the protocol should have: >> >> - Provides support for asynchronous notifications >> >>This support was removed from the protocol for several reasons, including: >> >> - Removal of multiple channels (or connections) per session >> - Inconsistent notification support capabilities for each application >>mapping >> - Lack of a configurable notification type selection (filtering) mechanism >> - Lack of consensus on feature importance >> - Lack of time to reach consensus on all these issues >> >>Some time has passed, and there is now WG consensus to finish this >>work item, however the single line in the original charter needs to >>be expanded and this work scoped in much more detail. >> >>The NETCONF Notification work shall consist of the following: >> >> - Specify the message (capability exchange) details to >> support notifications. >> - Specify the application mapping details to support notifications. >> - Specify the protocol syntax and semantics of a notification message. >> - Specify a mechanism for controlling the delivery (turn on/off) >> of notifications during a session. >> - Specify a mechanism for selectively receiving a configurable subset >>of all >> possible notification types. >> >>An individual submission Internet Draft has been proposed to the WG >>as the starting point for this work. Unless there are any strong >>objections or alternate proposals, the WG shall adopt the document >>identified as 'draft-chisholm-netconf-event-01.txt' as the starting >>point for this work. >> >>Goals and Milestones >> >> Dec 05 Update charter >> Jan 06 Submit first version of NETCONF Notifications document >> Sep 06 Begin WGLC of NETCONF Notifications document >> Dec 06 Submit final version of NETCONF Notifications document to >>IESG for >> consideration >> >> >> >> >>-- >>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 Nov 21 14:06:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeH0C-00011R-S3 for netconf-archive@megatron.ietf.org; Mon, 21 Nov 2005 14:06:56 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24441 for ; Mon, 21 Nov 2005 14:06:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeGrs-000Fpu-61 for netconf-data@psg.com; Mon, 21 Nov 2005 18:58:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.129.242.56] (helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeGrq-000FpR-VD for netconf@ops.ietf.org; Mon, 21 Nov 2005 18:58:19 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id jALItBX16136 for ; Mon, 21 Nov 2005 13:55:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: notification charter proposal Date: Mon, 21 Nov 2005 13:58:09 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405CFC312@zcarhxm2.corp.nortel.com> Thread-Topic: notification charter proposal Thread-Index: AcXus4iQaaqYUZAbRZaxbfbIyxZwOQAF/4sw From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi Introducing the one-way-rpc mechanism is consistent with the Netconf architecture. It also allows the possibility of someday people adding other asynchronous operations with different behaviour. We should absolutely prioritize on what problems we want to solve via this sort of mechanism, but I don't see the value in precluding what sorts of information can be set in event messages. The only way we could really do it would be to explicitly state that people can't use the protocol to perform these functions or to put restrictions on the solution that make it unsuitable for use by these. The former is odd and the latter is just as likely to cause problems for your 'legitimate' uses as those you wish to discourage. Event Message is a much better term in my books. The system generates an event and an event message gets sent. Notification brings up connotations of SNMP Traps, which never could have been used to send security audit logs or to mirror configuration. I'm not adamant that the term shouldn't be used, but it isn't obviously the right one either. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Monday, November 21, 2005 10:42 AM To: Tom Petch Cc: netconf@ops.ietf.org Subject: Re: notification charter proposal Tom Petch wrote: >Andy > >Notifications or events, or asynchronous messages? > >As Sharon says >"an asynchronous message, sometimes referred to as a > notification or event message" > >I get a slight sense of you and Sharon determinedly heading in=20 >different directions:-( > =20 > Notifications. I want to design features with a specific purpose. NETCONF is not a transport for arbitrary asynch messages. We will not have super-loose definitions of protocol elements, so that (for example) NETCONF notifications could be used to carry IPFIX reports or SW downloads or=20 whatever. I think there is something in the draft called a "one-way RPC" that I=20 really disagree with. Once you start down the slippery slope (e.g., declaring a notification=20 can be a 4 billion byte octet stream) then all implementations get more difficult, even=20 though hardly anyone wants this sort of "notification feature". >Tom Petch > =20 > Andy >----- Original Message ----- >From: "Andy Bierman" >To: >Sent: Thursday, November 17, 2005 3:27 AM >Subject: notification charter proposal > > > =20 > >>Hi, >> >>Please comment on the following charter text before it goes to the ADs >>for approval. >> >>thanks, >>Andy and Simon >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>NETCONF WG Charter Clarification proposal: >> >>The original NETCONF WG charter contains the following line item,=20 >>describing the characteristics that the protocol should have: >> >> - Provides support for asynchronous notifications >> >>This support was removed from the protocol for several reasons,=20 >>including: >> >> - Removal of multiple channels (or connections) per session >> - Inconsistent notification support capabilities for each application >>mapping >> - Lack of a configurable notification type selection (filtering)=20 >>mechanism >> - Lack of consensus on feature importance >> - Lack of time to reach consensus on all these issues >> >>Some time has passed, and there is now WG consensus to finish this=20 >>work item, however the single line in the original charter needs to be >>expanded and this work scoped in much more detail. >> >>The NETCONF Notification work shall consist of the following: >> >> - Specify the message (capability exchange) details to >> support notifications. >> - Specify the application mapping details to support notifications. >> - Specify the protocol syntax and semantics of a notification=20 >>message. >> - Specify a mechanism for controlling the delivery (turn on/off) >> of notifications during a session. >> - Specify a mechanism for selectively receiving a configurable subset >>of all >> possible notification types. >> >>An individual submission Internet Draft has been proposed to the WG as >>the starting point for this work. Unless there are any strong=20 >>objections or alternate proposals, the WG shall adopt the document=20 >>identified as 'draft-chisholm-netconf-event-01.txt' as the starting=20 >>point for this work. >> >>Goals and Milestones >> >> Dec 05 Update charter >> Jan 06 Submit first version of NETCONF Notifications document >> Sep 06 Begin WGLC of NETCONF Notifications document >> Dec 06 Submit final version of NETCONF Notifications document to >>IESG for >> consideration >> >> >> >> >>-- >>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 > -- 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 Nov 21 14:26:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeHIt-0005YB-OP for netconf-archive@megatron.ietf.org; Mon, 21 Nov 2005 14:26:15 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26872 for ; Mon, 21 Nov 2005 14:25:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeHDT-000HWL-QJ for netconf-data@psg.com; Mon, 21 Nov 2005 19:20:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeHDR-000HVq-ED for netconf@ops.ietf.org; Mon, 21 Nov 2005 19:20:37 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 21 Nov 2005 11:20:37 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jALJKYeS020408; Mon, 21 Nov 2005 11:20:35 -0800 (PST) Received: from [212.254.247.6] (ams-clip-vpn-dhcp4233.cisco.com [10.61.80.136]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jALJSson016366; Mon, 21 Nov 2005 11:28:56 -0800 Message-ID: <43821DFF.8050207@cisco.com> Date: Mon, 21 Nov 2005 20:20:31 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051025) MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: notification charter proposal References: <713043CE8B8E1348AF3C546DBE02C1B405CFC312@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B405CFC312@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=333; t=1132601336; x=1133033536; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20notification=20charter=20proposal| From:Eliot=20Lear=20| Date:Mon,=2021=20Nov=202005=2020=3A20=3A31=20+0100| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=D/hPJOOo2y/T/Ym83Q1+vA51gYxOqddTNspcd1VHptLyP5ImGiWpllN9YlkAnZe9buyDrcMs Wq9IQepOGJfsCMMYEMwH/NQzXI9RMM3hVHUnXYJvTvi7qp68MufcND8e0GeFg6tgV1wvltowgCW lFG8YCymgIcnb665TdgZZm+8= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sharon, I tend to agree with you that "event message" is a better term. However, I also wonder if this is architecturally severable from the netconf base. If so, I don't know that you even need one way RPCs. You just do your own schema. I think it's fine to have a netconf capability to indicate that one end can send such notifications, and provide a means to map it accordingly with mapping updates. Eliot -- 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 Nov 21 15:41:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeITo-00004q-5C for netconf-archive@megatron.ietf.org; Mon, 21 Nov 2005 15:41:36 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06136 for ; Mon, 21 Nov 2005 15:40:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeIJT-000MGC-88 for netconf-data@psg.com; Mon, 21 Nov 2005 20:30:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1EeIJR-000MG0-WA for netconf@ops.ietf.org; Mon, 21 Nov 2005 20:30:54 +0000 Received: (qmail 32411 invoked by uid 78); 21 Nov 2005 20:30:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.55 with SMTP; 21 Nov 2005 20:30:51 -0000 Message-ID: <43822E7A.90706@andybierman.com> Date: Mon, 21 Nov 2005 12:30:50 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: notification charter proposal References: <713043CE8B8E1348AF3C546DBE02C1B405CFC312@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B405CFC312@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sharon Chisholm wrote: >hi > >Introducing the one-way-rpc mechanism is consistent with the Netconf >architecture. It also allows the possibility of someday people adding >other asynchronous operations with different behaviour. > >We should absolutely prioritize on what problems we want to solve via >this sort of mechanism, but I don't see the value in precluding what >sorts of information can be set in event messages. The only way we could >really do it would be to explicitly state that people can't use the >protocol to perform these functions or to put restrictions on the >solution that make it unsuitable for use by these. The former is odd >and the latter is just as likely to cause problems for your 'legitimate' >uses as those you wish to discourage. > > I disagree. I like to clearly define functionality as clearly as possible up front, so later on in WGLC, nobody can claim this feature is broken because it can't do some new thing they just thought of. We don't list all the things the protocol doesn't have. We specify in detail the things it does have. >Event Message is a much better term in my books. The system generates an >event and an event message gets sent. Notification brings up >connotations of SNMP Traps, which never could have been used to send >security audit logs or to mirror configuration. I'm not adamant that the >term shouldn't be used, but it isn't obviously the right one either. > > I don't confuse SNMP Notification with SNMP Trap, but many people do. IMO, the term Event Message implies some sort of Event occurred, which is being reported. This of course implies an Event Model, and perhaps more. The term Notification simply means one peer is notifying the other peer of something. I don't want to reinvent the concept of an SNMP Notification. Why is a NETCONF notification so different? I don't mean silly details like snmpContextEngineID, but the purpose of a notification. I don't care if you want to include a REALLY BIG varbind list, but at some point, we have to face reality and at least advertise a max-msg-size. Right now we have the lame discover-by-error max-msg-size. That's what it comes down to really. If you advertise a max-msg-size of 4 billion, then go ahead and receive your giant notifications and have fun. But don't expect everyone to set max-msg-size that high. >Sharon > > Andy > >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Andy Bierman >Sent: Monday, November 21, 2005 10:42 AM >To: Tom Petch >Cc: netconf@ops.ietf.org >Subject: Re: notification charter proposal > > >Tom Petch wrote: > > > >>Andy >> >>Notifications or events, or asynchronous messages? >> >>As Sharon says >>"an asynchronous message, sometimes referred to as a >> notification or event message" >> >>I get a slight sense of you and Sharon determinedly heading in >>different directions:-( >> >> >> >> >Notifications. > >I want to design features with a specific purpose. >NETCONF is not a transport for arbitrary asynch messages. We will not >have super-loose definitions of protocol elements, so that (for example) >NETCONF notifications could be used to carry IPFIX reports or SW >downloads or >whatever. >I think there is something in the draft called a "one-way RPC" that I >really disagree with. >Once you start down the slippery slope (e.g., declaring a notification >can be a 4 billion >byte octet stream) then all implementations get more difficult, even >though hardly anyone >wants this sort of "notification feature". > > > >>Tom Petch >> >> >> >> > >Andy > > > >>----- Original Message ----- >>From: "Andy Bierman" >>To: >>Sent: Thursday, November 17, 2005 3:27 AM >>Subject: notification charter proposal >> >> >> >> >> >> >>>Hi, >>> >>>Please comment on the following charter text before it goes to the ADs >>> >>> > > > >>>for approval. >>> >>>thanks, >>>Andy and Simon >>> >>>============================================================ >>> >>>NETCONF WG Charter Clarification proposal: >>> >>>The original NETCONF WG charter contains the following line item, >>>describing the characteristics that the protocol should have: >>> >>> - Provides support for asynchronous notifications >>> >>>This support was removed from the protocol for several reasons, >>>including: >>> >>>- Removal of multiple channels (or connections) per session >>>- Inconsistent notification support capabilities for each application >>> >>> > > > >>>mapping >>>- Lack of a configurable notification type selection (filtering) >>>mechanism >>>- Lack of consensus on feature importance >>>- Lack of time to reach consensus on all these issues >>> >>>Some time has passed, and there is now WG consensus to finish this >>>work item, however the single line in the original charter needs to be >>> >>> > > > >>>expanded and this work scoped in much more detail. >>> >>>The NETCONF Notification work shall consist of the following: >>> >>>- Specify the message (capability exchange) details to >>> support notifications. >>>- Specify the application mapping details to support notifications. >>>- Specify the protocol syntax and semantics of a notification >>>message. >>>- Specify a mechanism for controlling the delivery (turn on/off) >>> of notifications during a session. >>>- Specify a mechanism for selectively receiving a configurable subset >>>of all >>> possible notification types. >>> >>>An individual submission Internet Draft has been proposed to the WG as >>> >>> > > > >>>the starting point for this work. Unless there are any strong >>>objections or alternate proposals, the WG shall adopt the document >>>identified as 'draft-chisholm-netconf-event-01.txt' as the starting >>>point for this work. >>> >>>Goals and Milestones >>> >>> Dec 05 Update charter >>> Jan 06 Submit first version of NETCONF Notifications document >>> Sep 06 Begin WGLC of NETCONF Notifications document >>> Dec 06 Submit final version of NETCONF Notifications document to >>>IESG for >>> consideration >>> >>> >>> >>> >>>-- >>>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: > > > > -- 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 Nov 21 16:16:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeJ1D-0004mq-5S for netconf-archive@megatron.ietf.org; Mon, 21 Nov 2005 16:16:07 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13238 for ; Mon, 21 Nov 2005 16:15:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeIvo-000PKj-Ru for netconf-data@psg.com; Mon, 21 Nov 2005 21:10:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeIvm-000PJp-6W for netconf@ops.ietf.org; Mon, 21 Nov 2005 21:10:30 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jALLAN104916 for ; Mon, 21 Nov 2005 16:10:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: notification charter proposal Date: Mon, 21 Nov 2005 16:09:59 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405CFC52C@zcarhxm2.corp.nortel.com> Thread-Topic: notification charter proposal Thread-Index: AcXu2ntMybAtTvyGQzKts110o6xWvgABTQwg From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi How does a management agent send out a Notification without an event system triggering it to do so? I think it is a part of all architectures, whether it is a well-defined entity or implicit within the rest of the system. Sharon -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com]=20 Sent: Monday, November 21, 2005 3:31 PM To: Chisholm, Sharon [CAR:5K50:EXCH] Cc: netconf@ops.ietf.org Subject: Re: notification charter proposal Sharon Chisholm wrote: >hi > >Introducing the one-way-rpc mechanism is consistent with the Netconf=20 >architecture. It also allows the possibility of someday people adding=20 >other asynchronous operations with different behaviour. > >We should absolutely prioritize on what problems we want to solve via=20 >this sort of mechanism, but I don't see the value in precluding what=20 >sorts of information can be set in event messages. The only way we=20 >could really do it would be to explicitly state that people can't use=20 >the protocol to perform these functions or to put restrictions on the=20 >solution that make it unsuitable for use by these. The former is odd=20 >and the latter is just as likely to cause problems for your=20 >'legitimate' uses as those you wish to discourage. > =20 > I disagree. I like to clearly define functionality as clearly as possible up front, so later on in WGLC, nobody can claim this feature is broken because it can't do some new thing they just thought of. We don't list all the things the protocol doesn't have. We specify in detail the things it does have. >Event Message is a much better term in my books. The system generates=20 >an event and an event message gets sent. Notification brings up=20 >connotations of SNMP Traps, which never could have been used to send=20 >security audit logs or to mirror configuration. I'm not adamant that=20 >the term shouldn't be used, but it isn't obviously the right one=20 >either. > =20 > I don't confuse SNMP Notification with SNMP Trap, but many people do. IMO, the term Event Message implies some sort of Event occurred, which is being reported. This of course implies an Event Model, and perhaps more. The term Notification simply means one peer is notifying the other peer of something.=20 I don't want to reinvent the concept of an SNMP Notification. Why is a NETCONF notification so different? I don't mean silly details like snmpContextEngineID, but the purpose of a notification. I don't care if you want to include a REALLY BIG varbind list, but at some point, we have to face reality and at least advertise a max-msg-size. Right now we have the lame discover-by-error max-msg-size. That's what it comes down to really. If you advertise a max-msg-size of 4 billion, then go ahead and receive your giant notifications and=20 have fun. But don't expect everyone to set max-msg-size that high. >Sharon > =20 > Andy > >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Andy Bierman >Sent: Monday, November 21, 2005 10:42 AM >To: Tom Petch >Cc: netconf@ops.ietf.org >Subject: Re: notification charter proposal > > >Tom Petch wrote: > > =20 > >>Andy >> >>Notifications or events, or asynchronous messages? >> >>As Sharon says >>"an asynchronous message, sometimes referred to as a >> notification or event message" >> >>I get a slight sense of you and Sharon determinedly heading in >>different directions:-( >>=20 >> >> =20 >> >Notifications. > >I want to design features with a specific purpose. >NETCONF is not a transport for arbitrary asynch messages. We will not=20 >have super-loose definitions of protocol elements, so that (for=20 >example) NETCONF notifications could be used to carry IPFIX reports or=20 >SW downloads or whatever. >I think there is something in the draft called a "one-way RPC" that I=20 >really disagree with. >Once you start down the slippery slope (e.g., declaring a notification=20 >can be a 4 billion >byte octet stream) then all implementations get more difficult, even=20 >though hardly anyone >wants this sort of "notification feature". > > =20 > >>Tom Petch >>=20 >> >> =20 >> > >Andy > > =20 > >>----- Original Message ----- >>From: "Andy Bierman" >>To: >>Sent: Thursday, November 17, 2005 3:27 AM >>Subject: notification charter proposal >> >> >>=20 >> >> =20 >> >>>Hi, >>> >>>Please comment on the following charter text before it goes to the=20 >>>ADs >>> =20 >>> > > =20 > >>>for approval. >>> >>>thanks, >>>Andy and Simon >>> >>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>>NETCONF WG Charter Clarification proposal: >>> >>>The original NETCONF WG charter contains the following line item, >>>describing the characteristics that the protocol should have: >>> >>> - Provides support for asynchronous notifications >>> >>>This support was removed from the protocol for several reasons, >>>including: >>> >>>- Removal of multiple channels (or connections) per session >>>- Inconsistent notification support capabilities for each application >>> =20 >>> > > =20 > >>>mapping >>>- Lack of a configurable notification type selection (filtering) >>>mechanism >>>- Lack of consensus on feature importance >>>- Lack of time to reach consensus on all these issues >>> >>>Some time has passed, and there is now WG consensus to finish this >>>work item, however the single line in the original charter needs to be >>> =20 >>> > > =20 > >>>expanded and this work scoped in much more detail. >>> >>>The NETCONF Notification work shall consist of the following: >>> >>>- Specify the message (capability exchange) details to >>> support notifications. >>>- Specify the application mapping details to support notifications. >>>- Specify the protocol syntax and semantics of a notification >>>message. >>>- Specify a mechanism for controlling the delivery (turn on/off) >>> of notifications during a session. >>>- Specify a mechanism for selectively receiving a configurable subset >>>of all >>> possible notification types. >>> >>>An individual submission Internet Draft has been proposed to the WG=20 >>>as >>> =20 >>> > > =20 > >>>the starting point for this work. Unless there are any strong >>>objections or alternate proposals, the WG shall adopt the document=20 >>>identified as 'draft-chisholm-netconf-event-01.txt' as the starting=20 >>>point for this work. >>> >>>Goals and Milestones >>> >>> Dec 05 Update charter >>> Jan 06 Submit first version of NETCONF Notifications document >>> Sep 06 Begin WGLC of NETCONF Notifications document >>> Dec 06 Submit final version of NETCONF Notifications document to >>>IESG for >>> consideration >>> >>> >>> >>> >>>-- >>>to unsubscribe send a message to netconf-request@ops.ietf.org with=20 >>>the >>> =20 >>> > > =20 > >>>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=20 >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=20 >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: From owner-netconf@ops.ietf.org Mon Nov 21 16:48:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeJWz-00024b-7I for netconf-archive@megatron.ietf.org; Mon, 21 Nov 2005 16:48:57 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16636 for ; Mon, 21 Nov 2005 16:48:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeJQY-0001vj-7H for netconf-data@psg.com; Mon, 21 Nov 2005 21:42:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeJQX-0001vY-M3 for netconf@ops.ietf.org; Mon, 21 Nov 2005 21:42:17 +0000 Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25]) by borg.juniper.net with ESMTP; 21 Nov 2005 13:42:18 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,357,1125903600"; d="scan'208"; a="512619755:sNHT21235996" Received: from photon.jnpr.net ([172.24.18.198]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Nov 2005 13:42:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Multiple candidate datstores Date: Mon, 21 Nov 2005 13:41:55 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D440D30C4A6@photon.jnpr.net> Thread-Topic: Multiple candidate datstores Thread-Index: AcXqmGnPlhwtVvgPTIazINuhJgiyCAES7aDg From: "Rob Enns" To: "Balazs Lengyel" , X-OriginalArrivalTime: 21 Nov 2005 21:42:16.0734 (UTC) FILETIME=[7118EBE0:01C5EEE4] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable As currently specified, there's only 1 candidate datastore. We deferred specifying support for user defined (that is, named) configuration=20 datastores to a future revision of NETCONF. Rob=20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel > Sent: Wednesday, November 16, 2005 2:22 AM > To: netconf@ops.ietf.org > Subject: Multiple candidate datstores >=20 > 1) Is it allowed to have multiple candidate data-stores or just one ? > 2) How do we address each ? > 3) Can we indicate in the commit operation which datastrore=20 > do we want to commit ? >=20 > regards > --=20 > Balazs Lengyel Ericsson Hungary Ltd. >=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: From owner-netconf@ops.ietf.org Mon Nov 21 17:28:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeK9T-0000FT-Mg for netconf-archive@megatron.ietf.org; Mon, 21 Nov 2005 17:28:43 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20905 for ; Mon, 21 Nov 2005 17:28:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeK3E-0004oI-Ip for netconf-data@psg.com; Mon, 21 Nov 2005 22:22:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1EeK3D-0004nv-Dw for netconf@ops.ietf.org; Mon, 21 Nov 2005 22:22:15 +0000 Received: (qmail 20909 invoked by uid 78); 21 Nov 2005 22:22:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.52 with SMTP; 21 Nov 2005 22:22:14 -0000 Message-ID: <43824894.60407@andybierman.com> Date: Mon, 21 Nov 2005 14:22:12 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: notification charter proposal References: <713043CE8B8E1348AF3C546DBE02C1B405CFC52C@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B405CFC52C@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sharon Chisholm wrote: >hi > >How does a management agent send out a Notification without an event >system triggering it to do so? I think it is a part of all >architectures, whether it is a well-defined entity or implicit within >the rest of the system. > > Maybe I'm worrying about it too much, but it seems like you are creating yet another CLR here. Can 1 NC peer send another NC peer the message "No activity has occurred in the last hour"? Or does the message have to be "designed" as an Inactivity Event in the one-and-only Official NETCONF Agent Architecture? And Event Messages only go from Agents to Managers, etc. I would rather focus on the operational features that must be agreed upon, without trying to specify too much architecture. IMO, it's too early in the technology cycle to standardize that. Let's work on stuff that has "proven operational value" and spend our debate-energy trying to agree what that means. For starters, should there be a minimum max-message size in NETCONF? If so, what should it be? 1500 bytes? 65535 bytes? More? I wonder if there is any consensus on this very specific detail. >Sharon > > Andy >-----Original Message----- >From: Andy Bierman [mailto:ietf@andybierman.com] >Sent: Monday, November 21, 2005 3:31 PM >To: Chisholm, Sharon [CAR:5K50:EXCH] >Cc: netconf@ops.ietf.org >Subject: Re: notification charter proposal > > >Sharon Chisholm wrote: > > > >>hi >> >>Introducing the one-way-rpc mechanism is consistent with the Netconf >>architecture. It also allows the possibility of someday people adding >>other asynchronous operations with different behaviour. >> >>We should absolutely prioritize on what problems we want to solve via >>this sort of mechanism, but I don't see the value in precluding what >>sorts of information can be set in event messages. The only way we >>could really do it would be to explicitly state that people can't use >>the protocol to perform these functions or to put restrictions on the >>solution that make it unsuitable for use by these. The former is odd >>and the latter is just as likely to cause problems for your >>'legitimate' uses as those you wish to discourage. >> >> >> >> > >I disagree. >I like to clearly define functionality as clearly as possible up front, >so later on in WGLC, nobody can claim this feature is broken because it >can't do some new thing they just thought of. > >We don't list all the things the protocol doesn't have. >We specify in detail the things it does have. > > > >>Event Message is a much better term in my books. The system generates >>an event and an event message gets sent. Notification brings up >>connotations of SNMP Traps, which never could have been used to send >>security audit logs or to mirror configuration. I'm not adamant that >>the term shouldn't be used, but it isn't obviously the right one >>either. >> >> >> >> > >I don't confuse SNMP Notification with SNMP Trap, but many people do. >IMO, the term Event Message implies some sort of Event occurred, which >is being reported. This of course implies an Event Model, and perhaps >more. The term Notification simply means one peer is notifying the other >peer of something. > >I don't want to reinvent the concept of an SNMP Notification. Why is a >NETCONF notification so different? I don't mean silly details like >snmpContextEngineID, but the purpose of a notification. > >I don't care if you want to include a REALLY BIG varbind list, but at >some point, we have to face reality and at least advertise a >max-msg-size. Right now we have the lame discover-by-error max-msg-size. >That's what it comes down to really. If you advertise a max-msg-size of >4 billion, then go ahead and receive your giant notifications and >have fun. >But don't expect everyone to set max-msg-size that high. > > > >>Sharon >> >> >> >> > >Andy > > > > >>-----Original Message----- >>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >> >> > > > >>Behalf Of Andy Bierman >>Sent: Monday, November 21, 2005 10:42 AM >>To: Tom Petch >>Cc: netconf@ops.ietf.org >>Subject: Re: notification charter proposal >> >> >>Tom Petch wrote: >> >> >> >> >> >>>Andy >>> >>>Notifications or events, or asynchronous messages? >>> >>>As Sharon says >>>"an asynchronous message, sometimes referred to as a >>> notification or event message" >>> >>>I get a slight sense of you and Sharon determinedly heading in >>>different directions:-( >>> >>> >>> >>> >>> >>> >>Notifications. >> >>I want to design features with a specific purpose. >>NETCONF is not a transport for arbitrary asynch messages. We will not >>have super-loose definitions of protocol elements, so that (for >>example) NETCONF notifications could be used to carry IPFIX reports or >>SW downloads or whatever. >>I think there is something in the draft called a "one-way RPC" that I >>really disagree with. >>Once you start down the slippery slope (e.g., declaring a notification >>can be a 4 billion >>byte octet stream) then all implementations get more difficult, even >>though hardly anyone >>wants this sort of "notification feature". >> >> >> >> >> >>>Tom Petch >>> >>> >>> >>> >>> >>> >>Andy >> >> >> >> >> >>>----- Original Message ----- >>>From: "Andy Bierman" >>>To: >>>Sent: Thursday, November 17, 2005 3:27 AM >>>Subject: notification charter proposal >>> >>> >>> >>> >>> >>> >>> >>> >>>>Hi, >>>> >>>>Please comment on the following charter text before it goes to the >>>>ADs >>>> >>>> >>>> >>>> >> >> >> >> >>>>for approval. >>>> >>>>thanks, >>>>Andy and Simon >>>> >>>>============================================================ >>>> >>>>NETCONF WG Charter Clarification proposal: >>>> >>>>The original NETCONF WG charter contains the following line item, >>>>describing the characteristics that the protocol should have: >>>> >>>> - Provides support for asynchronous notifications >>>> >>>>This support was removed from the protocol for several reasons, >>>>including: >>>> >>>>- Removal of multiple channels (or connections) per session >>>>- Inconsistent notification support capabilities for each application >>>> >>>> >>>> >>>> >> >> >> >> >>>>mapping >>>>- Lack of a configurable notification type selection (filtering) >>>>mechanism >>>>- Lack of consensus on feature importance >>>>- Lack of time to reach consensus on all these issues >>>> >>>>Some time has passed, and there is now WG consensus to finish this >>>>work item, however the single line in the original charter needs to >>>> >>>> >be > > >>>> >>>> >>>> >>>> >> >> >> >> >>>>expanded and this work scoped in much more detail. >>>> >>>>The NETCONF Notification work shall consist of the following: >>>> >>>>- Specify the message (capability exchange) details to >>>> support notifications. >>>>- Specify the application mapping details to support notifications. >>>>- Specify the protocol syntax and semantics of a notification >>>>message. >>>>- Specify a mechanism for controlling the delivery (turn on/off) >>>> of notifications during a session. >>>>- Specify a mechanism for selectively receiving a configurable subset >>>>of all >>>> possible notification types. >>>> >>>>An individual submission Internet Draft has been proposed to the WG >>>>as >>>> >>>> >>>> >>>> >> >> >> >> >>>>the starting point for this work. Unless there are any strong >>>>objections or alternate proposals, the WG shall adopt the document >>>>identified as 'draft-chisholm-netconf-event-01.txt' as the starting >>>>point for this work. >>>> >>>>Goals and Milestones >>>> >>>>Dec 05 Update charter >>>>Jan 06 Submit first version of NETCONF Notifications document >>>>Sep 06 Begin WGLC of NETCONF Notifications document >>>>Dec 06 Submit final version of NETCONF Notifications document to >>>>IESG for >>>> consideration >>>> >>>> >>>> >>>> >>>>-- >>>>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: >> >> >> >> >> >> > > > >-- >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 Nov 21 18:53:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeLTS-0003ic-89 for netconf-archive@megatron.ietf.org; Mon, 21 Nov 2005 18:53:26 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29612 for ; Mon, 21 Nov 2005 18:52:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeLKG-000B95-AS for netconf-data@psg.com; Mon, 21 Nov 2005 23:43:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeLKF-000B8p-L2 for netconf@ops.ietf.org; Mon, 21 Nov 2005 23:43:55 +0000 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 21 Nov 2005 15:43:55 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,358,1125903600"; d="scan'208,217"; a="511884792:sNHT25114840" Received: from photon.jnpr.net ([172.24.18.198]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Nov 2005 15:43:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: NETCONF notifications proposal Date: Mon, 21 Nov 2005 15:43:22 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D440D30C4C8@photon.jnpr.net> Thread-Topic: NETCONF notifications proposal Thread-Index: AcXu9VudPu6qJH3TQ5ywokTmPfXyKw== From: "Rob Enns" To: X-OriginalArrivalTime: 21 Nov 2005 23:43:54.0986 (UTC) FILETIME=[6F31CCA0:01C5EEF5] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable The original NETCONF drafts included a notification capability that had good agreement from the authors of the draft. We ended up taking it out in order to finish the draft in finite time, but now that we're considering updating the charter, I'd like to summarize (and slightly extend) that proposal. The principles of this approach are: o Nail down a simple transport o Pick a widely deployed notification model (syslog) for the initial release This is how we should approach notifications if we're going to add them back to the protocol. I do not want the WG to end up arguing about=20 what event classes make sense, etc. The operators use syslog and SNMP traps, and we're not going to get them to switch by inventing something new for NETCONF. Notification Capability: ----------------------- urn:ietf:params:netconf:capability:notifications:1.0 Requesting Notifications: ------------------------ The notification capability adds the and operations. Notification format is specified on element. http://xml.resource.org/profiles/syslog/COOKED=20 Notification Formats: -------------------- In the interest of reusing existing standards and catering to the most widely deployed eventing mechanism used by operators, the formats supported for 1.0 are the RFC 3195 RAW and COOKED syslog formats. http://xml.resource.org/profiles/syslog/RAW http://xml.resource.org/profiles/syslog/COOKED See also the structured data approach from draft-ietf-syslog-protocol-15.txt. =20 Filtering Notifications: ----------------------- Notification filters can be specified on the operation: http://xml.resource.org/profiles/syslog/COOKED=20 event[starts-with(@tag, "RSVP")] http://xml.resource.org/profiles/syslog/RAW=20 RSVP* Notification Transport: ---------------------- Notifications either occupy their own channel or must be in-between successive elements (in other words, notifications don't interrupt an ). Notification Examples: --------------------- RFC 3195 RAW: ------------ Oct 18 16:01:37 dent rsvpd[2958]: RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0 RFC 3195 RAW (with structured data from draft-ietf-syslog-protocol-15): ---------------------------------------------------------------------- 1 8 6 00 2005-10-18T16:01:37Z dent rsvpd 2958 RSVP_NBRUP [exampleSDID@0 neighbor=3D"10.5.14.2" interface=3D"fe-1/3/0.0"] RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0 RFC 3195 COOKED: --------------- RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0 -- 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 Nov 21 20:47:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeNFw-0004ff-J0 for netconf-archive@megatron.ietf.org; Mon, 21 Nov 2005 20:47:36 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15920 for ; Mon, 21 Nov 2005 20:46:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeN6x-000J9v-NY for netconf-data@psg.com; Tue, 22 Nov 2005 01:38:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeN6x-000J9k-6f for netconf@ops.ietf.org; Tue, 22 Nov 2005 01:38:19 +0000 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by kremlin.juniper.net with ESMTP; 21 Nov 2005 17:38:19 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,358,1125903600"; d="scan'208"; a="511897425:sNHT21540616" Received: from photon.jnpr.net ([172.24.18.198]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Nov 2005 17:38:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Transaction support in Netconf Date: Mon, 21 Nov 2005 17:37:31 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D440D30C4ED@photon.jnpr.net> Thread-Topic: Transaction support in Netconf Thread-Index: AcXvAhtzjtOdjApORceUkAh64TV+dAAAwXlw From: "Rob Enns" To: , "Andy Bierman" Cc: X-OriginalArrivalTime: 22 Nov 2005 01:38:18.0660 (UTC) FILETIME=[6A435640:01C5EF05] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > I talked to Simon and various IESG members about setting up another > > mailing list on ietf.org for implementation discussion. This was > > done for diffserv I believe. Maybe now we should try to set that > > up. >=20 > Since you mention it, diffserv was the specific case I had in mind > where implementation discussions were pretty much discouraged on the > diffserv mailing list. Personally, I did not like this approach very > much since I believe implementation and even early deployment > experience is extremely useful (and this list can sustain some more > traffic I would say). So I would prefer to _not_ follow the diffserv > model. I agree. My experience with fresh specs is that the first few implementors find lots of issues that the WG could use to improve the spec. So discussing on the netconf list would be helpful. Rob -- 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 Nov 22 03:32:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeTZm-00063B-2V for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 03:32:30 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17163 for ; Tue, 22 Nov 2005 03:31:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeTPH-000HGs-JS for netconf-data@psg.com; Tue, 22 Nov 2005 08:21:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeTPF-000HGJ-HP for netconf@ops.ietf.org; Tue, 22 Nov 2005 08:21:37 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 02FCD4C291; Tue, 22 Nov 2005 09:21:36 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 13639-10; Tue, 22 Nov 2005 09:21:34 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 9FC414C25E; Tue, 22 Nov 2005 09:21:34 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 962AD52E23C; Tue, 22 Nov 2005 09:21:32 +0100 (CET) Date: Tue, 22 Nov 2005 09:21:32 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: netconf@ops.ietf.org Subject: Re: notification charter proposal Message-ID: <20051122082132.GA736@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , netconf@ops.ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B405CFC312@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B405CFC312@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk On Mon, Nov 21, 2005 at 01:58:09PM -0500, Sharon Chisholm wrote: > Event Message is a much better term in my books. The system generates an > event and an event message gets sent. Notification brings up > connotations of SNMP Traps, which never could have been used to send > security audit logs or to mirror configuration. I'm not adamant that the > term shouldn't be used, but it isn't obviously the right one either. I prefer the term "notification" over other terms such as "event message" or "event report" which have been used in other places. I recall that we had a short discussion about this terminology with Dave Sidor (ITU) at the NMRG meeting in Austin since ITU/ISO folks have some slightly different terminology but we finally agreed that the IETF terminology is actually not a bad one. Some of you might remember that discussion (which by the way led to the information model vs. data model RFC - perhaps we should have also produced a document defining terms such events, notifications, alarms, etc). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Nov 22 03:56:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeTxC-0005yp-QS for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 03:56:42 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19098 for ; Tue, 22 Nov 2005 03:56:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeToY-000JSZ-01 for netconf-data@psg.com; Tue, 22 Nov 2005 08:47:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeToX-000JSC-8P for netconf@ops.ietf.org; Tue, 22 Nov 2005 08:47:45 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 754784C2D0; Tue, 22 Nov 2005 09:47:44 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 15765-06; Tue, 22 Nov 2005 09:47:43 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 2EEC84C25F; Tue, 22 Nov 2005 09:47:43 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 324DB52E294; Tue, 22 Nov 2005 09:46:41 +0100 (CET) Date: Tue, 22 Nov 2005 09:46:40 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: netconf@ops.ietf.org Subject: Re: notification charter proposal Message-ID: <20051122084640.GB736@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , netconf@ops.ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B405CFC312@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B405CFC312@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk On Mon, Nov 21, 2005 at 01:58:09PM -0500, Sharon Chisholm wrote: > Introducing the one-way-rpc mechanism is consistent with the Netconf > architecture. It also allows the possibility of someday people adding > other asynchronous operations with different behaviour. I think the question to asked is whether a notification message needs an application layer acknowledgement and if so what the semantics are or whether we can get away without such an application layer acknowledgement. Some options are: a) The notification sender sends a notification and hopes that it will be understood by the receiver. b) The notification sender sends a notification and gets a confirmation that the notification was understood to the extend that it could be handed over to an entity dealing with notifications. (This is what SNMP notifications actually do.) c) The notification sender sends a notification and gets a confirmation that an entity dealing with notifications actually understood the semantics associated with the notification. Once we understand and agree on the semantics we want to have (at the moment a) seems to be on the table), we know whether we need a response or if we can get away with a one-way message (in which case I agree that the so called RPC layer should be extended to support this). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Nov 22 04:18:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeUHs-0006wv-TF for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 04:18:05 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20977 for ; Tue, 22 Nov 2005 04:17:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeUB6-000L2Y-UE for netconf-data@psg.com; Tue, 22 Nov 2005 09:11:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [198.152.13.100] (helo=tierw.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.54 (FreeBSD)) id 1EeUB6-000L2J-9x for netconf@ops.ietf.org; Tue, 22 Nov 2005 09:11:04 +0000 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id jAM8uhnB004474 for ; Tue, 22 Nov 2005 03:56:43 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id jAM8tRnB002638 for ; Tue, 22 Nov 2005 03:55:37 -0500 (EST) 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: RE: notification charter proposal Date: Tue, 22 Nov 2005 11:09:44 +0200 Message-ID: Thread-Topic: notification charter proposal Thread-Index: AcXu6pFNcS8XPb/bTRySRMv14ea1HAAWWbqA From: "Romascanu, Dan \(Dan\)" To: "Andy Bierman" , "Sharon Chisholm" Cc: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > For starters, should there be a minimum max-message size in NETCONF? > If so, what should it be? 1500 bytes? 65535 bytes? More? I=20 > wonder if there is any consensus on this very specific detail. >=20 >=20 Is this a notification (or event message) related question, or a generic NETCONF issue? FWIW, if the 1500 bytes figure is related in anyway with the approximate max length of a Ethernet package payload, the IEEE 802.3 WG is extending this value to 2k, so we would like to align with this new standard value rather than falling into a backwards compatibility CLR.=20 Regards, 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 Tue Nov 22 04:10:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeUAI-0003W1-TQ for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 04:10:14 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20258 for ; Tue, 22 Nov 2005 04:09:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeU4O-000KZn-Ux for netconf-data@psg.com; Tue, 22 Nov 2005 09:04:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [152.81.1.70] (helo=macker.loria.fr) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeU4L-000KZU-Jv for netconf@ops.ietf.org; Tue, 22 Nov 2005 09:04:05 +0000 Received: from localhost.loria.fr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 394E45E9E0 for ; Tue, 22 Nov 2005 10:04:02 +0100 (CET) X-Amavix: Anti-virus check done by ClamAV X-Amavix: Scanned by Amavix Received: from [152.81.8.136] (sydney.loria.fr [152.81.8.136]) by macker.loria.fr (Postfix) with ESMTP id E61AE5D75E for ; Tue, 22 Nov 2005 10:03:49 +0100 (CET) Message-ID: <4382DF47.30404@loria.fr> Date: Tue, 22 Nov 2005 10:05:11 +0100 From: Vincent Cridlig User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: netconf@ops.ietf.org Subject: Re: notification charter proposal References: <713043CE8B8E1348AF3C546DBE02C1B405CFC52C@zcarhxm2.corp.nortel.com> <43824894.60407@andybierman.com> In-Reply-To: <43824894.60407@andybierman.com> Content-Type: multipart/mixed; boundary="------------050104060702060400090704" Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------050104060702060400090704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > For starters, should there be a minimum max-message size in NETCONF? > If so, what should it be? 1500 bytes? 65535 bytes? More? I wonder if > there is any consensus on this very specific detail. In our implementation, we experiment such sizes: - around 1600 bytes for a single physical network interface config (ipv4, v6, mac, mtu, netmask, ...) *without* the stats. This number grows proportionally with the number of network interfaces. - around 3400 bytes for a single physical network interface config (ipv4, v6, mac, mtu, netmask, ...) *with* the stats. - around 10000 bytes for a simple BGP config. - around 25000 bytes for a installed RPM package list (this example is more specific to system config than network config but well...) So, for the copy-config operation and a large data model, I would say at least 65535 bytes for a minimum max-message size. Vincent --------------050104060702060400090704 Content-Type: text/x-vcard; charset=utf-8; name="vincent.cridlig.vcf" Content-Disposition: attachment; filename="vincent.cridlig.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Vincent Cridlig n:Cridlig;Vincent org:LORIA - INRIA Lorraine;Madynes adr:;;;Nancy;;;France email;internet:cridligv@loria.fr title:PhD Student tel;work:+33 (0)3 83 59 20 48 url:http://www.loria.fr/~cridligv version:2.1 end:vcard --------------050104060702060400090704-- -- 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 Nov 22 06:03:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeVwF-0000Yk-RU for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 06:03:52 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02808 for ; Tue, 22 Nov 2005 06:03:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeVmV-0000y2-MT for netconf-data@psg.com; Tue, 22 Nov 2005 10:53:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeVmU-0000xo-Iv for netconf@ops.ietf.org; Tue, 22 Nov 2005 10:53:46 +0000 Received: from pc6 (1Cust175.tnt9.lnd4.gbr.da.uu.net [62.188.138.175]) by blaster.systems.pipex.net (Postfix) with SMTP id C51C4E0005A9; Tue, 22 Nov 2005 10:53:35 +0000 (GMT) Message-ID: <000701c5ef4a$5ce420c0$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Andy Bierman" Cc: References: <437BEA88.4030904@andybierman.com> <03f901c5eea6$6c4b8e80$0601a8c0@pc6> <4381EAD3.8000602@andybierman.com> Subject: Re: notification charter proposal Date: Tue, 22 Nov 2005 10:50:56 +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 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Andy Bierman" To: "Tom Petch" Cc: Sent: Monday, November 21, 2005 4:42 PM Subject: Re: notification charter proposal > Tom Petch wrote: > > >Andy > > > >Notifications or events, or asynchronous messages? > > > >As Sharon says > >"an asynchronous message, sometimes referred to as a > > notification or event message" > > > >I get a slight sense of you and Sharon determinedly heading in different > >directions:-( > > > > > Notifications. > > I want to design features with a specific purpose. > NETCONF is not a transport for arbitrary asynch messages. We will not have > super-loose definitions of protocol elements, so that (for example) NETCONF > notifications could be used to carry IPFIX reports or SW downloads or > whatever. > I think there is something in the draft called a "one-way RPC" that I > really disagree with. > Once you start down the slippery slope (e.g., declaring a notification > can be a 4 billion > byte octet stream) then all implementations get more difficult, even > though hardly anyone > wants this sort of "notification feature". > > Andy > Yes, I can see that and it makes me think that there needs to be something about that in the charter, clarifying what a notification is; otherwise, by simultaneously adopting 'draft-chisholm-netconf-event-01.txt', I think we are implicitly taking on board whatever that says. I always associate the term notification with SNMPv3 - I don't see it used elsewhere - which does not appear to define it but implies it is asynchronous, an unsolicited transmission, an event notification; and there is an implicit size limit because of UDP, something NETCONF lacks. The original charter did have asynchronous in it, which seems right to me, but I would like something about limiting the size as well, to stop people including a storage dump with the restart notification, but I don't have a good wording for it - perhaps 'a notification is a brief, asynchronous message indicating that an event has occurred'. > >----- Original Message ----- > >From: "Andy Bierman" > >To: > >Sent: Thursday, November 17, 2005 3:27 AM > >Subject: notification charter proposal > >>Hi, > >> > >>Please comment on the following charter text before it goes to the > >>ADs for approval. > >> > >>thanks, > >>Andy and Simon > >> > >>============================================================ > >> > >>NETCONF WG Charter Clarification proposal: > >> > >>The original NETCONF WG charter contains the following line item, > >>describing the characteristics that the protocol should have: > >> > >> - Provides support for asynchronous notifications > >> > >>This support was removed from the protocol for several reasons, including: > >> > >> - Removal of multiple channels (or connections) per session > >> - Inconsistent notification support capabilities for each application > >>mapping > >> - Lack of a configurable notification type selection (filtering) mechanism > >> - Lack of consensus on feature importance > >> - Lack of time to reach consensus on all these issues > >> > >>Some time has passed, and there is now WG consensus to finish this > >>work item, however the single line in the original charter needs to > >>be expanded and this work scoped in much more detail. > >> > >>The NETCONF Notification work shall consist of the following: > >> > >> - Specify the message (capability exchange) details to > >> support notifications. > >> - Specify the application mapping details to support notifications. > >> - Specify the protocol syntax and semantics of a notification message. > >> - Specify a mechanism for controlling the delivery (turn on/off) > >> of notifications during a session. > >> - Specify a mechanism for selectively receiving a configurable subset > >>of all > >> possible notification types. > >> > >>An individual submission Internet Draft has been proposed to the WG > >>as the starting point for this work. Unless there are any strong > >>objections or alternate proposals, the WG shall adopt the document > >>identified as 'draft-chisholm-netconf-event-01.txt' as the starting > >>point for this work. > >> > >>Goals and Milestones > >> > >> Dec 05 Update charter > >> Jan 06 Submit first version of NETCONF Notifications document > >> Sep 06 Begin WGLC of NETCONF Notifications document > >> Dec 06 Submit final version of NETCONF Notifications document to > >>IESG for > >> consideration > >> -- 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 Nov 22 06:30:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeWLa-0001iJ-7i for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 06:30:02 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05171 for ; Tue, 22 Nov 2005 06:29:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeWDV-0002Pw-V9 for netconf-data@psg.com; Tue, 22 Nov 2005 11:21:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeWDS-0002PY-FA for netconf@ops.ietf.org; Tue, 22 Nov 2005 11:21:38 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 61BD24C25F; Tue, 22 Nov 2005 12:21:37 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 04166-08; Tue, 22 Nov 2005 12:21:35 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id EF1A34C260; Tue, 22 Nov 2005 12:21:34 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id C7EC152E602; Tue, 22 Nov 2005 12:21:32 +0100 (CET) Date: Tue, 22 Nov 2005 12:21:32 +0100 From: Juergen Schoenwaelder To: Tom Petch Cc: Andy Bierman , netconf@ops.ietf.org Subject: Re: notification charter proposal Message-ID: <20051122112132.GC1078@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Tom Petch , Andy Bierman , netconf@ops.ietf.org References: <437BEA88.4030904@andybierman.com> <03f901c5eea6$6c4b8e80$0601a8c0@pc6> <4381EAD3.8000602@andybierman.com> <000701c5ef4a$5ce420c0$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000701c5ef4a$5ce420c0$0601a8c0@pc6> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk On Tue, Nov 22, 2005 at 10:50:56AM +0100, Tom Petch wrote: > I always associate the term notification with SNMPv3 - I don't see > it used elsewhere - which does not appear to define it but implies > it is asynchronous, an unsolicited transmission, an event > notification; and there is an implicit size limit because of UDP, > something NETCONF lacks. I think the term notification is not that unusual - even Corba has a "notification service". > The original charter did have asynchronous in it, which seems right > to me, but I would like something about limiting the size as well, > to stop people including a storage dump with the restart > notification, but I don't have a good wording for it - perhaps 'a > notification is a brief, asynchronous message indicating that an > event has occurred'. I believe it is not a good approach to try to prevent people from mis-using a protocol by means of rules or definitions (basically this is the source of CLRs). I favour an approach where a document spells out why it is a really bad idea to use a certain protocol feature in a certain way. I think the current netconf protocol spec does not define minimum required message sizes for the RPC or operations layer. Introducing such constraints for notifications to prevent their misuse I think is not helpful. In fact, it might be more helpful if during the greeting boxes could just advertise the message sizes they support, much like ESMTP does it. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Nov 22 07:02:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeWrQ-0005Zq-D6 for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 07:02:56 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08044 for ; Tue, 22 Nov 2005 07:02:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeWjI-0004IB-3i for netconf-data@psg.com; Tue, 22 Nov 2005 11:54:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.247.154.161] (helo=swip.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeWjH-0004Hw-Br for netconf@ops.ietf.org; Tue, 22 Nov 2005 11:54:31 +0000 X-T2-Posting-ID: P5HZhTV1iTSvFccgWTR5dA== Received: from [213.100.166.180] (HELO localhost) by mailfe06.swip.net (CommuniGate Pro SMTP 5.0.1) with ESMTP id 19853369 for netconf@ops.ietf.org; Tue, 22 Nov 2005 12:54:27 +0100 Date: Tue, 22 Nov 2005 12:54:18 +0100 (CET) Message-Id: <20051122.125418.41891102.mbj@tail-f.com> To: netconf@ops.ietf.org Subject: minor typo in draft 09 From: Martin Bjorklund X-Mailer: Mew version 2.2rc2-mbj1 on Emacs 21.3 / 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 Content-Transfer-Encoding: 7bit Hi, There's a small typo in Appendix A which lists error codes. The description of data-missing mentions a 'modify' operation; it should probably be 'replace'? /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 Tue Nov 22 09:13:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeYtK-0008TY-8L for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 09:13:02 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21326 for ; Tue, 22 Nov 2005 09:12:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeYio-000CMF-7E for netconf-data@psg.com; Tue, 22 Nov 2005 14:02:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeYil-000CLV-5Y for netconf@ops.ietf.org; Tue, 22 Nov 2005 14:02:07 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jAME22808928; Tue, 22 Nov 2005 09:02:02 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: notification charter proposal Date: Tue, 22 Nov 2005 09:00:20 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D073939FC@zcarhxm0.corp.nortel.com> Thread-Topic: notification charter proposal Thread-Index: AcXvQwXfiHz/CA0iTwm98jx9cwC5NAAKT4qA From: "Glenn Waters" To: , "Sharon Chisholm" Cc: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > I think the question to asked is whether a notification message needs > an application layer acknowledgement and if so what the semantics are > or whether we can get away without such an application layer > acknowledgement. Some options are: >=20 > a) The notification sender sends a notification and hopes that it > will be understood by the receiver. Unless we can identify value in (b) below then I would pick this method. > b) The notification sender sends a notification and gets a confirmation > that the notification was understood to the extend that it could be > handed over to an entity dealing with notifications. (This is what > SNMP notifications actually do.) I don't think that there is enough value in sending a response in this case since there is little recourse the sender can take to correct the issue. There is the possibility the sender could reduce the message size but that can be handled in other ways (such as the receiver reconfiguring the max size the sender should send). I can't think of what else a sender would possibly do with a response. Maybe it would help to identify those items to help decide if a response would be useful. >=20 > c) The notification sender sends a notification and gets a confirmation > that an entity dealing with notifications actually understood the > semantics associated with the notification. Same as above only worse. > > Once we understand and agree on the semantics we want to have (at the > moment a) seems to be on the table), we know whether we need a > response or if we can get away with a one-way message (in which case I > agree that the so called RPC layer should be extended to support > this). >=20 > /js >=20 > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, > Germany >=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 Tue Nov 22 09:13:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeYu6-0000WK-8s for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 09:13:50 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21353 for ; Tue, 22 Nov 2005 09:13:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeYlt-000Cak-UY for netconf-data@psg.com; Tue, 22 Nov 2005 14:05:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeYlt-000CaM-Ac for netconf@ops.ietf.org; Tue, 22 Nov 2005 14:05:21 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jAME5F809692; Tue, 22 Nov 2005 09:05:16 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: notification charter proposal Date: Tue, 22 Nov 2005 09:04:11 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D07393A14@zcarhxm0.corp.nortel.com> Thread-Topic: notification charter proposal Thread-Index: AcXvVMVkYN5OXl5PSEial+vHLanqCAAGG2GQ From: "Glenn Waters" To: "Tom Petch" , "Andy Bierman" Cc: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Yes, I can see that and it makes me think that there needs to be something > about > that in the charter, clarifying what a notification is; otherwise, by > simultaneously adopting 'draft-chisholm-netconf-event-01.txt', I think we > are > implicitly taking on board whatever that says. I disagree with the last statement. By taking on draft-chisholm we have a starting point for discussions and we can decide how to edit the text to meet our requirements. Regards, /gww=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 Tue Nov 22 09:43:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeZMh-0006mQ-KZ for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 09:43:23 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25188 for ; Tue, 22 Nov 2005 09:42:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeZC0-000EeE-It for netconf-data@psg.com; Tue, 22 Nov 2005 14:32:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeZBx-000Edj-3k for netconf@ops.ietf.org; Tue, 22 Nov 2005 14:32:17 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 698AC4C2D0; Tue, 22 Nov 2005 15:32:14 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 27684-07; Tue, 22 Nov 2005 15:32:13 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 070C04C279; Tue, 22 Nov 2005 15:32:13 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 3117752E75D; Tue, 22 Nov 2005 15:32:11 +0100 (CET) Date: Tue, 22 Nov 2005 15:32:10 +0100 From: Juergen Schoenwaelder To: Glenn Waters Cc: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: notification charter proposal Message-ID: <20051122143210.GA1252@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Glenn Waters , Sharon Chisholm , netconf@ops.ietf.org References: <085091CB2CA14E4B8B163FFC37C84E9D073939FC@zcarhxm0.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D073939FC@zcarhxm0.corp.nortel.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk On Tue, Nov 22, 2005 at 09:00:20AM -0500, Glenn Waters wrote: > > b) The notification sender sends a notification and gets a confirmation > > that the notification was understood to the extend that it could be > > handed over to an entity dealing with notifications. (This is what > > SNMP notifications actually do.) > > I don't think that there is enough value in sending a response in this > case since there is little recourse the sender can take to correct the > issue. There is the possibility the sender could reduce the message size > but that can be handled in other ways (such as the receiver > reconfiguring the max size the sender should send). I can't think of > what else a sender would possibly do with a response. Maybe it would > help to identify those items to help decide if a response would be > useful. Knowledge of the fact that you were not understood can be very useful, even if you do not know how to make yourself understood. You are arguing from a very narrow protocol centric perspective and I agree that from this protocol centric perspective there is hardly something you can do. However, if you take a more system wide perspective, then I think one can easily make a case for b) and even for c). Note: I am not against a) nor am I against b) and c) - it is just important for me that once we talk about adding notifications, we better be clear what their semantics are and which role they can play in a systems view. /js PS: There are also strong ties here to notification logging (see the NOTIFICATION-LOG-MIB produced by the DISMAN WG). The information whether a notification was "understood" can actually be used to decide what remains in a log and what can be purged. Without such information, the notification originator actually has to log everything (and maybe rely on the receiver to clear log entries). -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Nov 22 10:07:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeZjf-00018v-M0 for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 10:07:07 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28076 for ; Tue, 22 Nov 2005 10:06:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeZcr-000Gfg-Oh for netconf-data@psg.com; Tue, 22 Nov 2005 15:00:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.129.242.56] (helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeZcq-000Geg-WC for netconf@ops.ietf.org; Tue, 22 Nov 2005 15:00:05 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id jAMEutO28953; Tue, 22 Nov 2005 09:56:55 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: notification charter proposal Date: Tue, 22 Nov 2005 09:59:08 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D07393B9A@zcarhxm0.corp.nortel.com> Thread-Topic: notification charter proposal Thread-Index: AcXvcZFh28tWWt5NTKi+Gx2VZEMYTQAA1N9A From: "Glenn Waters" To: Cc: "Sharon Chisholm" , Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > Note: I am not against a) nor am I against b) and c) - it is just > important for me that once we talk about adding notifications, we > better be clear what their semantics are and which role they can play > in a systems view. Absolutely agree. Let's continue the discussion. At this point I too am not against (a), (b), or (c) and understanding notifications role is critical. =20 > /js Regards, /gww=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 Tue Nov 22 10:47:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeaMc-00013N-MZ for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 10:47:22 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02287 for ; Tue, 22 Nov 2005 10:46:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeaCn-000IlR-2f for netconf-data@psg.com; Tue, 22 Nov 2005 15:37:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.54 (FreeBSD)) id 1EeaCm-000IlE-J1 for netconf@ops.ietf.org; Tue, 22 Nov 2005 15:37:12 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id jAMFb1Bm012977; Tue, 22 Nov 2005 07:37:02 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jAMFb1513646; Tue, 22 Nov 2005 07:37:01 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id jAMFgHYE089694; Tue, 22 Nov 2005 10:42:18 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200511221542.jAMFgHYE089694@idle.juniper.net> To: j.schoenwaelder@iu-bremen.de cc: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: notification charter proposal In-Reply-To: Your message of "Tue, 22 Nov 2005 09:46:40 +0100." <20051122084640.GB736@boskop.local> Date: Tue, 22 Nov 2005 10:42:17 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Juergen Schoenwaelder writes: >c) The notification sender sends a notification and gets a confirmation > that an entity dealing with notifications actually understood the > semantics associated with the notification. Dumb question: what does one do with a system that supports you option (c)? If I sent a notification, the receiver tells me my semantics are off, then what happens? I resend? I resend to another target? I auto-correct my semantics? Are there realistic options that I have as a non-intelligent notification sender? Thanks, Phil -- 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 Nov 22 10:47:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeaN3-0001Q8-Sg for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 10:47:50 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02316 for ; Tue, 22 Nov 2005 10:47:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeaGx-000J26-2R for netconf-data@psg.com; Tue, 22 Nov 2005 15:41:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1EeaGw-000J1r-99 for netconf@ops.ietf.org; Tue, 22 Nov 2005 15:41:30 +0000 Received: (qmail 16241 invoked by uid 78); 22 Nov 2005 15:41:29 -0000 Received: from unknown (HELO ?192.168.0.15?) (24.24.133.237) by 10.49.34.53 with SMTP; 22 Nov 2005 15:41:29 -0000 Message-ID: <43833C28.1000002@andybierman.com> Date: Tue, 22 Nov 2005 07:41:28 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: Tom Petch , netconf@ops.ietf.org Subject: Re: notification charter proposal References: <437BEA88.4030904@andybierman.com> <03f901c5eea6$6c4b8e80$0601a8c0@pc6> <4381EAD3.8000602@andybierman.com> <000701c5ef4a$5ce420c0$0601a8c0@pc6> <20051122112132.GC1078@boskop.local> In-Reply-To: <20051122112132.GC1078@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: >On Tue, Nov 22, 2005 at 10:50:56AM +0100, Tom Petch wrote: > > > >>I always associate the term notification with SNMPv3 - I don't see >>it used elsewhere - which does not appear to define it but implies >>it is asynchronous, an unsolicited transmission, an event >>notification; and there is an implicit size limit because of UDP, >>something NETCONF lacks. >> >> > >I think the term notification is not that unusual - even Corba has a >"notification service". > > > >>The original charter did have asynchronous in it, which seems right >>to me, but I would like something about limiting the size as well, >>to stop people including a storage dump with the restart >>notification, but I don't have a good wording for it - perhaps 'a >>notification is a brief, asynchronous message indicating that an >>event has occurred'. >> >> > >I believe it is not a good approach to try to prevent people from >mis-using a protocol by means of rules or definitions (basically this >is the source of CLRs). > >I favour an approach where a document spells out why it is a really >bad idea to use a certain protocol feature in a certain way. > >I think the current netconf protocol spec does not define minimum >required message sizes for the RPC or operations layer. Introducing >such constraints for notifications to prevent their misuse I think is >not helpful. In fact, it might be more helpful if during the greeting >boxes could just advertise the message sizes they support, much like >ESMTP does it. > > That would be fine with me. I brought up the issue because the problem is obviously worse for notifications than RPCs, because the lack of an application layer ACK (which effectively is). The reason for setting a minimum is to allow NMS developers to code to some reasonable minimum. The market will help keep things somewhat reasonable, but we could see a range from 1500 to 64K as the minimum. Is that OK? Andy >/js > > > -- 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 Nov 22 10:54:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeaTk-00064D-O8 for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 10:54:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03698 for ; Tue, 22 Nov 2005 10:54:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeaNw-000JUa-No for netconf-data@psg.com; Tue, 22 Nov 2005 15:48:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1EeaNw-000JUL-1r for netconf@ops.ietf.org; Tue, 22 Nov 2005 15:48:44 +0000 Received: (qmail 26372 invoked by uid 78); 22 Nov 2005 15:48:43 -0000 Received: from unknown (HELO ?192.168.0.15?) (24.24.133.237) by 10.49.34.61 with SMTP; 22 Nov 2005 15:48:43 -0000 Message-ID: <43833DDB.6070401@andybierman.com> Date: Tue, 22 Nov 2005 07:48:43 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Glenn Waters CC: Tom Petch , netconf@ops.ietf.org Subject: Re: notification charter proposal References: <085091CB2CA14E4B8B163FFC37C84E9D07393A14@zcarhxm0.corp.nortel.com> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D07393A14@zcarhxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Glenn Waters wrote: >>Yes, I can see that and it makes me think that there needs to be >> >> >something > > >>about >>that in the charter, clarifying what a notification is; otherwise, by >>simultaneously adopting 'draft-chisholm-netconf-event-01.txt', I think >> >> >we > > >>are >>implicitly taking on board whatever that says. >> >> > >I disagree with the last statement. By taking on draft-chisholm we have >a starting point for discussions and we can decide how to edit the text >to meet our requirements. > > Glenn is correct. It's even stronger than that. Once an individual I-D becomes a WG I-D, the individual(s) give up change control completely. There is no guarantee that any of the original text or even original authors will end up in the final RFC. (That would be very unusual, but possible.) I forget the RFC#. It's not 3979 (IPR) but that one may apply. >Regards, /gww > > 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 Tue Nov 22 11:25:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeaxK-0003ut-7v for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 11:25:18 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07864 for ; Tue, 22 Nov 2005 11:24:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeapK-000LRX-H4 for netconf-data@psg.com; Tue, 22 Nov 2005 16:17:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [204.127.202.55] (helo=sccrmhc11.comcast.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeapJ-000LRK-Q5 for netconf@ops.ietf.org; Tue, 22 Nov 2005 16:17:01 +0000 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc11) with SMTP id <20051122161700011000avrae>; Tue, 22 Nov 2005 16:17:01 +0000 Reply-To: From: "David B Harrington" To: "'Phil Shafer'" , Cc: "'Sharon Chisholm'" , Subject: RE: notification charter proposal Date: Tue, 22 Nov 2005 11:16:40 -0500 Message-ID: <001401c5ef80$28385540$0400a8c0@DJYXPY41> 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.2180 Thread-Index: AcXvfAd0PyAONTqvRVqa9uCogNVUyQAAPwAQ In-Reply-To: <200511221542.jAMFgHYE089694@idle.juniper.net> Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Phil, My impression is that option c) is similar to error codes in an SNMPv3 Response message that explains the problem, so the sender can try to correct the problem, such as by shortening a TooBig message by removing the largest varbind. I agree there are limited cases where a non-intelligent notification sender could auto-correct the semantics, and the TooBig issue could be handled via capabilities. One response might be to NOT resend, and to not send future notifications of a specific type, if the sender is made aware that specific notifications can not be handled due to a semantics problem. Another response might be to drop back to a different version or different protocol to get a message through. Some SNMP-based NMSs drop back to lesser versions and protocols when the default stops working, such as dropping from SNMPv3 to SNMPv1 to ping. It might also be useful if another notification was generated, either in netconf or syslog or snmp, that alerted the administrator that there is an interoperability problem related to a specific notification from managed device A to management application B. Dbh > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Phil Shafer > Sent: Tuesday, November 22, 2005 10:42 AM > To: j.schoenwaelder@iu-bremen.de > Cc: Sharon Chisholm; netconf@ops.ietf.org > Subject: Re: notification charter proposal > > Juergen Schoenwaelder writes: > >c) The notification sender sends a notification and gets a > confirmation > > that an entity dealing with notifications actually understood the > > semantics associated with the notification. > > Dumb question: what does one do with a system that supports you > option (c)? If I sent a notification, the receiver tells me my > semantics are off, then what happens? I resend? I resend to another > target? I auto-correct my semantics? Are there realistic options > that I have as a non-intelligent notification sender? > > Thanks, > Phil > > -- > 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 Tue Nov 22 12:53:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EecKz-0007X8-80 for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 12:53:49 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18794 for ; Tue, 22 Nov 2005 12:53:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EecDi-000104-PA for netconf-data@psg.com; Tue, 22 Nov 2005 17:46:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EecDg-0000za-8c for netconf@ops.ietf.org; Tue, 22 Nov 2005 17:46:16 +0000 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 22 Nov 2005 09:46:17 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,362,1125903600"; d="scan'208"; a="512768860:sNHT20542736" Received: from photon.jnpr.net ([172.24.18.198]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Nov 2005 09:46:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: minor typo in draft 09 Date: Tue, 22 Nov 2005 09:45:04 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D440D30C553@photon.jnpr.net> Thread-Topic: minor typo in draft 09 Thread-Index: AcXvW/hACUn1m7zQR1urvj01jvp7FwAL2LkQ From: "Rob Enns" To: "Martin Bjorklund" , X-OriginalArrivalTime: 22 Nov 2005 17:46:15.0667 (UTC) FILETIME=[A2DB5430:01C5EF8C] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Yes, fixed and thanks. Rob=20 > Hi, >=20 > There's a small typo in Appendix A which lists error codes. The > description of data-missing mentions a 'modify' operation; it should > probably be 'replace'? >=20 >=20 > /martin >=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: From owner-netconf@ops.ietf.org Tue Nov 22 14:06:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EedSz-0004RN-Qo for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 14:06:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26450 for ; Tue, 22 Nov 2005 14:05:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EedJF-0005VQ-Mv for netconf-data@psg.com; Tue, 22 Nov 2005 18:56:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.129.242.56] (helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EedJE-0005VF-M2 for netconf@ops.ietf.org; Tue, 22 Nov 2005 18:56:04 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id jAMIqZO21932; Tue, 22 Nov 2005 13:52:35 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: notification charter proposal Date: Tue, 22 Nov 2005 13:54:47 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D073940AF@zcarhxm0.corp.nortel.com> Thread-Topic: notification charter proposal Thread-Index: AcXvfAd0PyAONTqvRVqa9uCogNVUyQAAPwAQAAY0C3A= From: "Glenn Waters" To: , "Phil Shafer" , Cc: "Sharon Chisholm" , Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I view option (b) as being the most similar to SNMPv3 error codes. As I understood it, option (b) it is trying to indicate protocol level (error) responses. Option (c) is trying to indicate data level (semantic) responses. Regards, /gww=20 > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of David B Harrington > Sent: Tuesday, November 22, 2005 11:17 > To: 'Phil Shafer'; j.schoenwaelder@iu-bremen.de > Cc: Chisholm, Sharon [CAR:5K50:EXCH]; netconf@ops.ietf.org > Subject: RE: notification charter proposal >=20 > Hi Phil, >=20 > My impression is that option c) is similar to error codes in an SNMPv3 > Response message that explains the problem, so the sender can try to > correct the problem, such as by shortening a TooBig message by > removing the largest varbind. I agree there are limited cases where a > non-intelligent notification sender could auto-correct the semantics, > and the TooBig issue could be handled via capabilities. >=20 > One response might be to NOT resend, and to not send future > notifications of a specific type, if the sender is made aware that > specific notifications can not be handled due to a semantics problem. >=20 > Another response might be to drop back to a different version or > different protocol to get a message through. Some SNMP-based NMSs drop > back to lesser versions and protocols when the default stops working, > such as dropping from SNMPv3 to SNMPv1 to ping. >=20 > It might also be useful if another notification was generated, either > in netconf or syslog or snmp, that alerted the administrator that > there is an interoperability problem related to a specific > notification from managed device A to management application B. >=20 > Dbh >=20 > > -----Original Message----- > > From: owner-netconf@ops.ietf.org > > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Phil Shafer > > Sent: Tuesday, November 22, 2005 10:42 AM > > To: j.schoenwaelder@iu-bremen.de > > Cc: Sharon Chisholm; netconf@ops.ietf.org > > Subject: Re: notification charter proposal > > > > Juergen Schoenwaelder writes: > > >c) The notification sender sends a notification and gets a > > confirmation > > > that an entity dealing with notifications actually understood > the > > > semantics associated with the notification. > > > > Dumb question: what does one do with a system that supports you > > option (c)? If I sent a notification, the receiver tells me my > > semantics are off, then what happens? I resend? I resend to > another > > target? I auto-correct my semantics? Are there realistic options > > that I have as a non-intelligent notification sender? > > > > Thanks, > > Phil > > > > -- > > 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 > -- > 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 Tue Nov 22 14:06:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EedTK-0004e7-Nl for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 14:06:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26485 for ; Tue, 22 Nov 2005 14:05:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EedGx-0005Kj-7e for netconf-data@psg.com; Tue, 22 Nov 2005 18:53:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EedGw-0005KX-PA for netconf@ops.ietf.org; Tue, 22 Nov 2005 18:53:42 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 22 Nov 2005 10:53:41 -0800 X-IronPort-AV: i="3.97,362,1125903600"; d="scan'208"; a="233303274:sNHT23075392" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jAMIrd6a018820; Tue, 22 Nov 2005 10:53:40 -0800 (PST) Received: from [212.254.247.3] (ams-clip-vpn-dhcp81.cisco.com [10.61.64.81]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jAMJ1uKF026259; Tue, 22 Nov 2005 11:01:57 -0800 Message-ID: <43836932.8050303@cisco.com> Date: Tue, 22 Nov 2005 19:53:38 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051025) MIME-Version: 1.0 To: Rob Enns CC: Martin Bjorklund , netconf@ops.ietf.org Subject: Re: minor typo in draft 09 References: <062B922B6EC55149B5A267ECE78E5D440D30C553@photon.jnpr.net> In-Reply-To: <062B922B6EC55149B5A267ECE78E5D440D30C553@photon.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=93; t=1132686117; x=1133118317; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20minor=20typo=20in=20draft=2009| From:Eliot=20Lear=20| Date:Tue,=2022=20Nov=202005=2019=3A53=3A38=20+0100| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=aY6R4gk77JsYkBgzgGKmW2St2AZMbUPjjkFkncnPTrRwj1ttRipK2SnUV1BDymReLrnxAtV3 xAFH6U9nOjVmAMTs8oWecRPjMHN3DaFSbbqL7/IUYX9oaat9QhXzxHqWveIZtKXW7mQSfUIV/eI pSrNdBEh7GvWas5dGUOzQFGY= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Are these docs cooked? I'm holding off small editing changes for post IESG review on mine. Can we get to that now? -- 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 Nov 22 14:44:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eee43-0005p0-98 for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 14:44:28 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01631 for ; Tue, 22 Nov 2005 14:43:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eedw6-0008aP-9q for netconf-data@psg.com; Tue, 22 Nov 2005 19:36:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eedw5-0008aC-RS for netconf@ops.ietf.org; Tue, 22 Nov 2005 19:36:13 +0000 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by borg.juniper.net with ESMTP; 22 Nov 2005 11:36:14 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,362,1125903600"; d="scan'208"; a="512785893:sNHT21431856" Received: from photon.jnpr.net ([172.24.18.198]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Nov 2005 11:36:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: minor typo in draft 09 Date: Tue, 22 Nov 2005 11:35:58 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D440D30C596@photon.jnpr.net> Thread-Topic: minor typo in draft 09 Thread-Index: AcXvlhgVwLilvH9tREC31ia0PRXpqAABb/iA From: "Rob Enns" To: "Eliot Lear" Cc: "Martin Bjorklund" , X-OriginalArrivalTime: 22 Nov 2005 19:36:13.0337 (UTC) FILETIME=[FF5FE090:01C5EF9B] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Are these docs cooked? I'm holding off small editing changes for post > IESG review on mine. Can we get to that now? I think they are cooked (Andy, Simon could you comment?). I'm not planning to post any updates until we get the IESG review.=20 Rob -- 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 Nov 22 15:19:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeecQ-0004UR-Bm for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 15:19:58 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05886 for ; Tue, 22 Nov 2005 15:19:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeeTl-000Bbl-Rl for netconf-data@psg.com; Tue, 22 Nov 2005 20:11:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.55] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1EeeTl-000BbQ-04 for netconf@ops.ietf.org; Tue, 22 Nov 2005 20:11:01 +0000 Received: (qmail 2919 invoked from network); 22 Nov 2005 20:10:59 -0000 Received: from unknown (HELO ?192.168.0.15?) (24.24.133.237) by 10.49.34.115 with SMTP; 22 Nov 2005 20:10:59 -0000 Message-ID: <43837B54.8070106@andybierman.com> Date: Tue, 22 Nov 2005 12:11:00 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eliot Lear CC: Rob Enns , Martin Bjorklund , netconf@ops.ietf.org Subject: Re: minor typo in draft 09 References: <062B922B6EC55149B5A267ECE78E5D440D30C553@photon.jnpr.net> <43836932.8050303@cisco.com> In-Reply-To: <43836932.8050303@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eliot Lear wrote: >Are these docs cooked? I'm holding off small editing changes for post >IESG review on mine. Can we get to that now? > > Please hold edits for the next official rev, which will be AUTH48 unless there are fixes found during the review cycle before that. All the current drafts have been handed off to Bert, so let's not confuse things unless he asks for another rev. thanks, 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 Tue Nov 22 16:08:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EefNc-0001bZ-Cp for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 16:08:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12125 for ; Tue, 22 Nov 2005 16:08:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EefFx-000ElN-2F for netconf-data@psg.com; Tue, 22 Nov 2005 21:00:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EefFw-000Ekx-EI for netconf@ops.ietf.org; Tue, 22 Nov 2005 21:00:48 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jAML0ipf005899; Tue, 22 Nov 2005 15:00:45 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 22 Nov 2005 22:00:20 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508A47812@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Rob Enns , Eliot Lear Cc: Martin Bjorklund , netconf@ops.ietf.org Subject: RE: minor typo in draft 09 Date: Tue, 22 Nov 2005 22:00:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-netconf@ops.ietf.org Precedence: bulk I ahve them on my plate for anotehr (quick) check and then issue IETF Last Call. If they are real minor editorial things I'd suggest to not re-issue a new rev now. Maybe right after IETF last Call completes. Bert > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Rob Enns > Sent: Tuesday, November 22, 2005 20:36 > To: Eliot Lear > Cc: Martin Bjorklund; netconf@ops.ietf.org > Subject: RE: minor typo in draft 09 > > > > > Are these docs cooked? I'm holding off small editing > changes for post > > IESG review on mine. Can we get to that now? > > I think they are cooked (Andy, Simon could you comment?). > I'm not planning to post any updates until we get the IESG review. > > Rob > > -- > 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 Tue Nov 22 17:38:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eegmk-0007jC-TF for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 17:38:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22650 for ; Tue, 22 Nov 2005 17:38:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eege3-000KtQ-BQ for netconf-data@psg.com; Tue, 22 Nov 2005 22:29:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eege2-000KtE-Hc for netconf@ops.ietf.org; Tue, 22 Nov 2005 22:29:46 +0000 Received: from pc6 (1Cust17.tnt14.lnd4.gbr.da.uu.net [62.188.143.17]) by blaster.systems.pipex.net (Postfix) with SMTP id 2463FE0004B0; Tue, 22 Nov 2005 22:29:32 +0000 (GMT) Message-ID: <041701c5efab$97ffd8a0$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Andy Bierman" Cc: References: <437BEA88.4030904@andybierman.com> <03f901c5eea6$6c4b8e80$0601a8c0@pc6> <4381EAD3.8000602@andybierman.com> <000701c5ef4a$5ce420c0$0601a8c0@pc6> <20051122112132.GC1078@boskop.local> <43833C28.1000002@andybierman.com> Subject: Size matters was Re: notification charter proposal Date: Tue, 22 Nov 2005 22:27:02 +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 Content-Transfer-Encoding: 7bit Tom Petch ----- Original Message ----- From: "Andy Bierman" To: Cc: "Tom Petch" ; Sent: Tuesday, November 22, 2005 4:41 PM Subject: Re: notification charter proposal > > > > That would be fine with me. > I brought up the issue because the problem is obviously worse > for notifications than RPCs, because the lack of an application > layer ACK (which effectively is). > > The reason for setting a minimum is to allow NMS developers > to code to some reasonable minimum. The market will help > keep things somewhat reasonable, but we could see a range > from 1500 to 64K as the minimum. Is that OK? > > Andy > I raised size because there are references appearing on the list calling for something syslog-like and size has been an issue with syslog that has not been satisfactorily resolved. syslog unearthed two contrasting viewpoints, one that messages should not exceed 2k or even 1k, the other that 64k should be supported (for at least one application). Netconf is more virgin territory than syslog is but I do believe is setting a Maximum size, at least to start with; but I do not see this as anything to do with the charter:-). Tom Petch -- 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 Nov 22 18:08:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EehFF-0000JF-NM for netconf-archive@megatron.ietf.org; Tue, 22 Nov 2005 18:08:14 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25750 for ; Tue, 22 Nov 2005 18:07:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eeh8c-000NDV-8u for netconf-data@psg.com; Tue, 22 Nov 2005 23:01:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1Eeh8Z-000NDB-H2 for netconf@ops.ietf.org; Tue, 22 Nov 2005 23:01:19 +0000 Received: (qmail 28349 invoked by uid 78); 22 Nov 2005 23:01:16 -0000 Received: from unknown (HELO ?192.168.0.15?) (24.24.133.237) by 10.49.34.57 with SMTP; 22 Nov 2005 23:01:16 -0000 Message-ID: <4383A33B.1030108@andybierman.com> Date: Tue, 22 Nov 2005 15:01:15 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Petch CC: netconf@ops.ietf.org Subject: Re: Size matters was Re: notification charter proposal References: <437BEA88.4030904@andybierman.com> <03f901c5eea6$6c4b8e80$0601a8c0@pc6> <4381EAD3.8000602@andybierman.com> <000701c5ef4a$5ce420c0$0601a8c0@pc6> <20051122112132.GC1078@boskop.local> <43833C28.1000002@andybierman.com> <041701c5efab$97ffd8a0$0601a8c0@pc6> In-Reply-To: <041701c5efab$97ffd8a0$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tom Petch wrote: > >Tom Petch >----- Original Message ----- >From: "Andy Bierman" >To: >Cc: "Tom Petch" ; >Sent: Tuesday, November 22, 2005 4:41 PM >Subject: Re: notification charter proposal >> > > > >>That would be fine with me. >>I brought up the issue because the problem is obviously worse >>for notifications than RPCs, because the lack of an application >>layer ACK (which effectively is). >> >>The reason for setting a minimum is to allow NMS developers >>to code to some reasonable minimum. The market will help >>keep things somewhat reasonable, but we could see a range >>from 1500 to 64K as the minimum. Is that OK? >> >>Andy >> >> >> > >I raised size because there are references appearing on the list calling for >something syslog-like and size has been an issue with syslog that has not been >satisfactorily resolved. syslog unearthed two contrasting viewpoints, one that >messages should not exceed 2k or even 1k, the other that 64k should be supported >(for at least one application). > >Netconf is more virgin territory than syslog is but I do believe is setting a >Maximum size, at least to start with; but I do not see this as anything to do >with the charter:-). > > This is part of protocol syntax and semantics. IMO, the best approach is to have the NC peer advertise its max-message-size. The number should be an PositiveInteger, so that would set a theoretical max-message-size of 4G-1 bytes. A separate issue is whether there is a minimum an NC peer can set this parameter to, somewhat higher than zero. I don't see any consensus yet on how much higher to set the minimum. Another important issue: Can an NC peer (optionally?) send its max-message-size in the exchange? This doesn't mean the other NC peer has to do anything with the value, it just provides a good guess at the number instead of trying various message sizes to see what breaks. Advertising a max-message-size doesn't mean you won't get messages greater than that size. >Tom Petch > > > > 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 Wed Nov 23 03:26:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eepxj-0007Cb-4i for netconf-archive@megatron.ietf.org; Wed, 23 Nov 2005 03:26:43 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26806 for ; Wed, 23 Nov 2005 03:26:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EepoA-0009c6-QR for netconf-data@psg.com; Wed, 23 Nov 2005 08:16:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eepo9-0009bs-S2 for netconf@ops.ietf.org; Wed, 23 Nov 2005 08:16:50 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id BB7479C00C; Wed, 23 Nov 2005 09:25:10 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01363-05; Wed, 23 Nov 2005 09:25:07 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 4C9B49C00B; Wed, 23 Nov 2005 09:25:07 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: Size matters was Re: notification charter proposal MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Nov 2005 09:16:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3EDF@grfint2.intern.adiscon.com> Thread-Topic: Size matters was Re: notification charter proposal Thread-Index: AcXvtfTUsKJLCCrGSx+GveekfqYfMwAT1jhA From: "Rainer Gerhards" To: "Tom Petch" , "Andy Bierman" Cc: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable A comment from a lurker on this list. I have been working on syslog for the past 3 years and been through the size discussion several times. I have NOT read all documents of the NETCONF WG. > I raised size because there are references appearing on the=20 > list calling for > something syslog-like and size has been an issue with syslog=20 > that has not been > satisfactorily resolved. syslog unearthed two contrasting=20 > viewpoints, one that > messages should not exceed 2k or even 1k, the other that 64k=20 > should be supported > (for at least one application). In my point of view, this WG is in a far better situation than the syslog WG. The core problem with syslog is that it is strictly simplex, without any way that a receiver could tell the sender anything. So in syslog, there is no way a sender knows what size of message the receiver can process. If that would be known, the issue would be considerably less complex, as the sender could take appropriate measures (like stripping out non-essential information, sending multiple notifications, ...). If my understanding of NETCONF is correct, NETCONF has such capabilities. As such, it should be in a much better position to handle the size issue. Rainer Gerhards -- 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 Wed Nov 23 11:20:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EexMV-0007Zq-Qd for netconf-archive@megatron.ietf.org; Wed, 23 Nov 2005 11:20:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21922 for ; Wed, 23 Nov 2005 11:20:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EexBO-000KQq-4Q for netconf-data@psg.com; Wed, 23 Nov 2005 16:09:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EexBN-000KQZ-IA for netconf@ops.ietf.org; Wed, 23 Nov 2005 16:09:17 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jANG9FRq017865 for ; Wed, 23 Nov 2005 10:09:16 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Nov 2005 17:08:46 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508A47C47@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Netconf (E-mail)" Subject: AD review of: draft-ietf-netconf-prot-09.txt Date: Wed, 23 Nov 2005 17:09:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Just checking before I do IETF Last Call. Pls consider this early IETF Last Call comments. Do not issue a new rev. I am requesting IETF Last Call now. - Appendix C.1.3. I think appendix C.1.3. should fix urn:ietf:params:xml:ns:netconf:capability:{name}:1.0 into urn:ietf:params:netconf:capability:{name}:1.0 I know, you easily miss one if you make such changes. - Sections 10.1 and 10.2 I was checking with APPS AD Scot Hollenbeck, and he suggests Bert, I see one small problem right away. =A0They're asking IANA to both assign a namespace and to register a specific one. =A0You can't do both. If they change the word "assign" to "register" in the first sentence of sections 10.1 and 10.2 I think the meaning will be much clearer. - Section 10.3 So if I understand it correctly, then we do not allow any new assignments for capabilities now. We (as a WG? as the IESG? as the IETF?) may decide so later. But how is IANA to know how/when that happens? Can we say some words about it? Bert -- 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 Wed Nov 23 11:20:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EexMY-0007Z5-02 for netconf-archive@megatron.ietf.org; Wed, 23 Nov 2005 11:20:50 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21919 for ; Wed, 23 Nov 2005 11:20:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EexBR-000KRI-81 for netconf-data@psg.com; Wed, 23 Nov 2005 16:09:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EexBQ-000KR4-Mu for netconf@ops.ietf.org; Wed, 23 Nov 2005 16:09:20 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jANG9FBh017866 for ; Wed, 23 Nov 2005 10:09:16 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Nov 2005 17:08:46 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508A47C46@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Netconf (E-mail)" Subject: AD review of: draft-ietf-netconf-ssh-05.txt Date: Wed, 23 Nov 2005 17:09:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk Just checking before I do IETF Last Call. Pls consider this early IETF Last Call comments. Do not issue a new rev. I am requesting IETF Last Call now. - You may want to add to the IANA considerations that they list the port number assigned in that section And that the RFC editor is to update section 3 (two places) to replace the by the IANA assigned portnumber. - I worry a bit about the several secsh WG drafts that are normative. Do we have any idea if they are close to being finished? Bert -- 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 Wed Nov 23 11:26:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EexS5-0003Ur-Bt for netconf-archive@megatron.ietf.org; Wed, 23 Nov 2005 11:26:33 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22729 for ; Wed, 23 Nov 2005 11:25:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EexM5-000LK8-Rn for netconf-data@psg.com; Wed, 23 Nov 2005 16:20:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EexM1-000LJV-Vf for netconf@ops.ietf.org; Wed, 23 Nov 2005 16:20:18 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 38AE14C40D; Wed, 23 Nov 2005 17:20:16 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 15058-08; Wed, 23 Nov 2005 17:20:14 +0100 (CET) Received: from zupanc.iuhb02.iu-bremen.de (unknown [212.201.48.211]) by hermes.iu-bremen.de (Postfix) with ESMTP id CB6394C3B1; Wed, 23 Nov 2005 17:20:14 +0100 (CET) Received: by zupanc.iuhb02.iu-bremen.de (Postfix, from userid 501) id 8EBC052F3A9; Wed, 23 Nov 2005 17:20:13 +0100 (CET) Date: Wed, 23 Nov 2005 17:20:13 +0100 From: Juergen Schoenwaelder To: Phil Shafer Cc: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: notification charter proposal Message-ID: <20051123162013.GA2820@zupanc.iuhb02.iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Phil Shafer , Sharon Chisholm , netconf@ops.ietf.org References: <20051122084640.GB736@boskop.local> <200511221542.jAMFgHYE089694@idle.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200511221542.jAMFgHYE089694@idle.juniper.net> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk On Tue, Nov 22, 2005 at 10:42:17AM -0500, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >c) The notification sender sends a notification and gets a confirmation > > that an entity dealing with notifications actually understood the > > semantics associated with the notification. > > Dumb question: what does one do with a system that supports you > option (c)? If I sent a notification, the receiver tells me my > semantics are off, then what happens? I resend? I resend to another > target? I auto-correct my semantics? Are there realistic options > that I have as a non-intelligent notification sender? If you talk to a person, you can get back either a) nothing b) "I heard you" c) "I understood what you were saying" It of course depends on the smartness of the whole system how you react. Some humans are fine when they achieve b), some other implementations feel better if they know they have achieved c). Sure, implementation complexity goes up from a) to c) and the added value of c) might not be worth the extra effort it causes. So perhaps the decision is between a) and b). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Wed Nov 23 12:04:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eey2n-0000NV-84 for netconf-archive@megatron.ietf.org; Wed, 23 Nov 2005 12:04:29 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27362 for ; Wed, 23 Nov 2005 12:03:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EexwS-000O1U-SS for netconf-data@psg.com; Wed, 23 Nov 2005 16:57:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [66.154.82.3] (helo=cubert.e-centre.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EexwS-000O19-4a for netconf@ops.ietf.org; Wed, 23 Nov 2005 16:57:56 +0000 Received: from [10.3.1.19] (helo=barracuda2.stayonline.net) by cubert.e-centre.net with esmtp (Exim 4.50) id 1EexwQ-0008JT-QF; Wed, 23 Nov 2005 11:57:54 -0500 X-ASG-Debug-ID: 1132765074-28221-27-0 X-Barracuda-URL: http://10.3.1.19:8000/cgi-bin/mark.cgi Received: from et-sfo-4.site.stayonline.net (unknown [12.24.19.2]) by barracuda2.stayonline.net (Spam Firewall) with ESMTP id 51DB89AEF; Wed, 23 Nov 2005 11:57:54 -0500 (EST) Received: from ceili ([192.168.212.158]) by et-sfo-4.site.stayonline.net (8.12.6/8.12.6) with ESMTP id jANGuFwT027423; Wed, 23 Nov 2005 16:56:16 GMT From: "Margaret Wasserman" To: "'Wijnen, Bert \(Bert\)'" , "'Netconf \(E-mail\)'" X-ASG-Orig-Subj: RE: AD review of: draft-ietf-netconf-ssh-05.txt Subject: RE: AD review of: draft-ietf-netconf-ssh-05.txt Date: Wed, 23 Nov 2005 11:57:38 -0500 Message-ID: <000701c5f04f$05a9e4b0$9ed4a8c0@instant802.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15508A47C46@nl0006exch001u.nl.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXwSdZi/mNCEPNPRbq2AUuAvutGvgABL2Rg X-Virus-Scanned: by Barracuda Spam Firewall at stayonline.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=7.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.5506 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bert, > Pls consider this early IETF Last Call comments. > Do not issue a new rev. I am requesting IETF Last Call now. Thanks! > - You may want to add to the IANA considerations that they > list the port number assigned in that section > And that the RFC editor is to update section 3 (two places) > to replace the by the IANA assigned portnumber. That makes sense. I'll make this change along with any changes based on LC. > - I worry a bit about the several secsh WG drafts that are > normative. Do we have any idea if they are close to being > finished? All four of them are in the RFC Editor Queue. Margaret -- 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 Wed Nov 23 12:18:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeyGa-0004z8-95 for netconf-archive@megatron.ietf.org; Wed, 23 Nov 2005 12:18:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29567 for ; Wed, 23 Nov 2005 12:18:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeyAa-000P4D-0I for netconf-data@psg.com; Wed, 23 Nov 2005 17:12:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeyAX-000P42-D7 for netconf@ops.ietf.org; Wed, 23 Nov 2005 17:12:29 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 23 Nov 2005 09:12:29 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jANHBvsO023315; Wed, 23 Nov 2005 09:12:26 -0800 (PST) Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 09:12:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: notification charter proposal Date: Wed, 23 Nov 2005 09:12:14 -0800 Message-ID: <6E21698722408147BEA594E073E2B0AB0105B63E@xmb-sjc-223.amer.cisco.com> Thread-Topic: notification charter proposal Thread-Index: AcXwSeCCETAd/52QQzKE7XZipbfNugABkpCA From: "Hector Trevino \(htrevino\)" To: , "Phil Shafer" Cc: "Sharon Chisholm" , X-OriginalArrivalTime: 23 Nov 2005 17:12:15.0526 (UTC) FILETIME=[0D404460:01C5F051] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Back from vacation and just catching up on these discussions... I think that option "a" is sufficient, however, option "b" could also be included for those users that feel application level confirmations/acks are needed.=20 Hector =20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Wednesday, November 23, 2005 9:20 AM To: Phil Shafer Cc: Sharon Chisholm; netconf@ops.ietf.org Subject: Re: notification charter proposal On Tue, Nov 22, 2005 at 10:42:17AM -0500, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >c) The notification sender sends a notification and gets a confirmation > > that an entity dealing with notifications actually understood the > > semantics associated with the notification. >=20 > Dumb question: what does one do with a system that supports you=20 > option (c)? If I sent a notification, the receiver tells me my=20 > semantics are off, then what happens? I resend? I resend to another=20 > target? I auto-correct my semantics? Are there realistic options=20 > that I have as a non-intelligent notification sender? If you talk to a person, you can get back either a) nothing b) "I heard you" c) "I understood what you were saying" It of course depends on the smartness of the whole system how you react. Some humans are fine when they achieve b), some other implementations feel better if they know they have achieved c). Sure, implementation complexity goes up from a) to c) and the added value of c) might not be worth the extra effort it causes. So perhaps the decision is between a) and b). /js --=20 Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Wed Nov 23 12:40:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeybg-0003AB-8W for netconf-archive@megatron.ietf.org; Wed, 23 Nov 2005 12:40:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02209 for ; Wed, 23 Nov 2005 12:39:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeyUz-0000cv-7B for netconf-data@psg.com; Wed, 23 Nov 2005 17:33:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeyUy-0000ci-Iy for netconf@ops.ietf.org; Wed, 23 Nov 2005 17:33:36 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jANHXYtS021543 for ; Wed, 23 Nov 2005 11:33:35 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Nov 2005 18:33:05 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508A47C87@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Netconf (E-mail)" Subject: AD review for: Date: Wed, 23 Nov 2005 18:33:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk Just checking before I do IETF Last Call. Pls consider this early IETF Last Call comments. Do not issue a new rev. I am requesting IETF Last Call now. On page 5... I think you need to change: A: urn:ietf:params:xml:ns:netconf:capability:startup:1.0 into: A: urn:ietf:params:netconf:capability:startup:1.0 that is if you want to be insync with latest protocol draft, in fact, according to youre Norm Reference [1] you synced up with prot doc rev 7 while current one is 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 Wed Nov 23 12:53:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeyoA-0001dr-SS for netconf-archive@megatron.ietf.org; Wed, 23 Nov 2005 12:53:27 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03877 for ; Wed, 23 Nov 2005 12:52:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eeyi3-0001jN-Sk for netconf-data@psg.com; Wed, 23 Nov 2005 17:47:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eeyi3-0001jC-AR for netconf@ops.ietf.org; Wed, 23 Nov 2005 17:47:07 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jANHl5hx000710 for ; Wed, 23 Nov 2005 11:47:06 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Nov 2005 18:46:36 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508A47C89@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Netconf (E-mail)" Subject: AD review for: draft-ietf-netconf-beep-07.txt Date: Wed, 23 Nov 2005 18:47:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk Resending... forgot to fill out doc name Just checking before I do IETF Last Call. Pls consider this early IETF Last Call comments. Do not issue a new rev. I am requesting IETF Last Call now. On page 5... I think you need to change: A: urn:ietf:params:xml:ns:netconf:capability:startup:1.0 into: A: urn:ietf:params:netconf:capability:startup:1.0 that is if you want to be insync with latest protocol draft, in fact, according to youre Norm Reference [1] you synced up with prot doc rev 7 while current one is 9. Bert -- 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 Wed Nov 23 12:55:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeyq3-0002M6-T3 for netconf-archive@megatron.ietf.org; Wed, 23 Nov 2005 12:55:23 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04054 for ; Wed, 23 Nov 2005 12:54:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eeyjc-0001qf-M9 for netconf-data@psg.com; Wed, 23 Nov 2005 17:48:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eeyjb-0001qR-S9 for netconf@ops.ietf.org; Wed, 23 Nov 2005 17:48:43 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 23 Nov 2005 09:48:28 -0800 X-IronPort-AV: i="3.97,365,1125903600"; d="scan'208"; a="369465641:sNHT1038117486" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jANHmSCJ017449; Wed, 23 Nov 2005 09:48:28 -0800 (PST) Received: from [212.254.247.5] (ams-clip-vpn-dhcp276.cisco.com [10.61.65.20]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jANHugAh003045; Wed, 23 Nov 2005 09:56:42 -0800 Message-ID: <4384AB6B.4030108@cisco.com> Date: Wed, 23 Nov 2005 18:48:27 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051025) MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: "Netconf (E-mail)" Subject: Re: AD review for: References: <7D5D48D2CAA3D84C813F5B154F43B15508A47C87@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15508A47C87@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=31; t=1132768603; x=1133200803; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20AD=20review=20for=3A| From:Eliot=20Lear=20| Date:Wed,=2023=20Nov=202005=2018=3A48=3A27=20+0100| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=J8C+8hs2P/scfTdPvRk84IFwYrf4tHBPmhbE84dP+4liQWte647h5Q9B6n8weu130KuJBnPe qiiCbaejOulpLR2pUPDjq2slgMjeoTA2FJUiWWo9nDJnQf/8wsAMvT5OaY+bnmXuDFlgwUDJyGN brU3Whg3BdY6qMB6NnEAtfgs= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Doh! Missed a pageful. Thanks. Eliot -- 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 Wed Nov 23 13:15:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eez9f-0000pj-Of for netconf-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:15:40 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06526 for ; Wed, 23 Nov 2005 13:14:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eez2Z-0003bb-3e for netconf-data@psg.com; Wed, 23 Nov 2005 18:08:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eez2Y-0003Zn-58 for netconf@ops.ietf.org; Wed, 23 Nov 2005 18:08:18 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id jANI7UiO006538; Wed, 23 Nov 2005 10:07:31 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Nov 2005 10:09:47 -0800 Message-ID: From: "McDonald, Ira" To: "'j.schoenwaelder@iu-bremen.de'" , Phil Shafer Cc: Sharon Chisholm , netconf@ops.ietf.org Subject: RE: notification charter proposal Date: Wed, 23 Nov 2005 10:09:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, I urge you folks to choose at least option (b), i.e., protocol level acknowledgement of receipt of a notification. This both improves the sender logging functionality (as Juergen S. has observed) and also lets the sender know that the notification receiver is indeed alive and running. Repeated missing acks should lead to abandonment of notifications to that target, at least for some reasonable period of time. Notifications that are not received are NOT notifications - they're just noise on the network. Unconfirmed notifications are only defensible when delivered by a connectionless transport (e.g., UDP). SNMP Informs (confirmed) significantly improve the functionality of mid-level SNMP managers. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Juergen Schoenwaelder > Sent: Wednesday, November 23, 2005 11:20 AM > To: Phil Shafer > Cc: Sharon Chisholm; netconf@ops.ietf.org > Subject: Re: notification charter proposal > > > On Tue, Nov 22, 2005 at 10:42:17AM -0500, Phil Shafer wrote: > > Juergen Schoenwaelder writes: > > >c) The notification sender sends a notification and gets a > confirmation > > > that an entity dealing with notifications actually > understood the > > > semantics associated with the notification. > > > > Dumb question: what does one do with a system that supports you > > option (c)? If I sent a notification, the receiver tells me my > > semantics are off, then what happens? I resend? I resend > to another > > target? I auto-correct my semantics? Are there realistic options > > that I have as a non-intelligent notification sender? > > If you talk to a person, you can get back either > > a) nothing > b) "I heard you" > c) "I understood what you were saying" > > It of course depends on the smartness of the whole system how you > react. Some humans are fine when they achieve b), some other > implementations feel better if they know they have achieved c). > > Sure, implementation complexity goes up from a) to c) and the added > value of c) might not be worth the extra effort it causes. So perhaps > the decision is between a) and b). > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > > -- > 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 Wed Nov 23 13:17:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EezBP-0001Ke-F1 for netconf-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:17:27 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06822 for ; Wed, 23 Nov 2005 13:16:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eez3d-0003fb-7H for netconf-data@psg.com; Wed, 23 Nov 2005 18:09:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eez3a-0003fN-K8 for netconf@ops.ietf.org; Wed, 23 Nov 2005 18:09:22 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 23 Nov 2005 10:08:21 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jANI8Es6021248; Wed, 23 Nov 2005 10:08:18 -0800 (PST) Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 10:08:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Size matters was Re: notification charter proposal Date: Wed, 23 Nov 2005 10:08:10 -0800 Message-ID: <6E21698722408147BEA594E073E2B0AB0105B6A7@xmb-sjc-223.amer.cisco.com> Thread-Topic: Size matters was Re: notification charter proposal Thread-Index: AcXvuOnGMMXMXhURTMSPoLvFeIypqQAnQY6A From: "Hector Trevino \(htrevino\)" To: "Andy Bierman" , "Tom Petch" Cc: X-OriginalArrivalTime: 23 Nov 2005 18:08:12.0171 (UTC) FILETIME=[DDF7A5B0:01C5F058] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I agree that this is part of the protocol definition but I see it as outside the scope of the charter definition. I'd assume none of this will be included in the charter. I don't think the spec should set a hard limit on the max message size. I agree w/Juergen about not limiting the protocol but rather allowing implementations to advertise their max message sizes (if one is set). It may be better to say something like app layer message segmentation is not allowed. But recommendations/guidelines for max message sizes should be provided in the spec.=20 Hector =20 =20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Tuesday, November 22, 2005 4:01 PM To: Tom Petch Cc: netconf@ops.ietf.org Subject: Re: Size matters was Re: notification charter proposal Tom Petch wrote: > >Tom Petch >----- Original Message ----- >From: "Andy Bierman" >To: >Cc: "Tom Petch" ; >Sent: Tuesday, November 22, 2005 4:41 PM >Subject: Re: notification charter proposal > > > =20 > >>That would be fine with me. >>I brought up the issue because the problem is obviously worse for=20 >>notifications than RPCs, because the lack of an application layer ACK=20 >>(which effectively is). >> >>The reason for setting a minimum is to allow NMS developers to code to >>some reasonable minimum. The market will help keep things somewhat=20 >>reasonable, but we could see a range from 1500 to 64K as the minimum. >>Is that OK? >> >>Andy >> >> =20 >> > >I raised size because there are references appearing on the list=20 >calling for something syslog-like and size has been an issue with=20 >syslog that has not been satisfactorily resolved. syslog unearthed two >contrasting viewpoints, one that messages should not exceed 2k or even=20 >1k, the other that 64k should be supported (for at least one application). > >Netconf is more virgin territory than syslog is but I do believe is=20 >setting a Maximum size, at least to start with; but I do not see this=20 >as anything to do with the charter:-). > =20 > This is part of protocol syntax and semantics. IMO, the best approach is to have the NC peer advertise its max-message-size. The number should be an PositiveInteger, so that would set a theoretical max-message-size of 4G-1 bytes. A separate issue is whether there is a minimum an NC peer can set this parameter to, somewhat higher than zero. I don't see any consensus yet on how much higher to set the minimum. Another important issue: Can an NC peer (optionally?) send its max-message-size in the exchange? This doesn't mean the other NC peer has to do anything with the value, it just provides a good guess at the number instead of trying various message sizes to see what breaks. Advertising a max-message-size doesn't mean you won't get messages greater than that size.=20 >Tom Petch > > > =20 > Andy > > =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 Wed Nov 23 13:20:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EezEW-0003Sa-Gq for netconf-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:20:40 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07231 for ; Wed, 23 Nov 2005 13:20:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eez7c-00043O-SY for netconf-data@psg.com; Wed, 23 Nov 2005 18:13:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eez7c-00043C-70 for netconf@ops.ietf.org; Wed, 23 Nov 2005 18:13:32 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 23 Nov 2005 10:13:32 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jANIDVCJ014746; Wed, 23 Nov 2005 10:13:31 -0800 (PST) Received: from [212.254.247.5] (ams-clip-vpn-dhcp276.cisco.com [10.61.65.20]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jANILhWG003309; Wed, 23 Nov 2005 10:21:44 -0800 Message-ID: <4384B149.7040203@cisco.com> Date: Wed, 23 Nov 2005 19:13:29 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051025) MIME-Version: 1.0 To: "McDonald, Ira" CC: "'j.schoenwaelder@iu-bremen.de'" , Phil Shafer , Sharon Chisholm , netconf@ops.ietf.org Subject: Re: notification charter proposal References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=147; t=1132770106; x=1133202306; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20notification=20charter=20proposal| From:Eliot=20Lear=20| Date:Wed,=2023=20Nov=202005=2019=3A13=3A29=20+0100| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=L+XEXOSwHdKnzQSAJVNRg0yY9dFsn8iE66e1cjKQorKcNXI2VMfbLXbhnrmH2iqBzAWWlssV rO2EhUccvAJSzWlnIiF1QYKmDKWw16aE3v1o99UthfaLsV6GlI0phDt6up+hxeYDCESZpcr3b2g ri5ty08/o+5nZUtcZQWL0tvs= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit McDonald, Ira wrote: > Hi, > > I urge you folks to choose at least option (b), i.e., protocol > level acknowledgement of receipt of a notification. You get this for free with BEEP. -- 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 Wed Nov 23 13:34:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EezRT-0005f1-L9 for netconf-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:34:03 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08503 for ; Wed, 23 Nov 2005 13:33:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EezKs-0005ER-Bx for netconf-data@psg.com; Wed, 23 Nov 2005 18:27:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EezKr-0005EF-Ht for netconf@ops.ietf.org; Wed, 23 Nov 2005 18:27:13 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jANIR1I00669; Wed, 23 Nov 2005 13:27:01 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: notification charter proposal Date: Wed, 23 Nov 2005 13:26:06 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D073ED702@zcarhxm0.corp.nortel.com> Thread-Topic: notification charter proposal Thread-Index: AcXwWrMVUFaP4biBSlOABp0IN8xY2gAABxdQ From: "Glenn Waters" To: "Eliot Lear" , "McDonald, Ira" Cc: , "Phil Shafer" , "Sharon Chisholm" , Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Ahh, the challenges of multiple transports with differing features. So, if we chose (b) then we don't *need* to do anything the protocol for BEEP transport but we *need* to include something in the protocol for SSH transport (and SOAP I just don't know). Of course Netconf is transport independent so if we chose (b) then we *must* include in acks in the proto which means the BEEP transport will have an extra ack. Cheers, /gww=20 > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Eliot Lear > Sent: Wednesday, November 23, 2005 13:13 > To: McDonald, Ira > Cc: 'j.schoenwaelder@iu-bremen.de'; Phil Shafer; Chisholm, Sharon > [CAR:5K50:EXCH]; netconf@ops.ietf.org > Subject: Re: notification charter proposal >=20 > McDonald, Ira wrote: > > Hi, > > > > I urge you folks to choose at least option (b), i.e., protocol > > level acknowledgement of receipt of a notification. >=20 > You get this for free with BEEP. >=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 Wed Nov 23 13:46:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eezd6-0004mm-ED for netconf-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:46:04 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10143 for ; Wed, 23 Nov 2005 13:45:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EezVh-0006GS-33 for netconf-data@psg.com; Wed, 23 Nov 2005 18:38:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [204.9.221.21] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EezVe-0006G3-CU for netconf@ops.ietf.org; Wed, 23 Nov 2005 18:38:22 +0000 Received: from [66.93.138.196] (account margaret HELO ceili) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 603883; Wed, 23 Nov 2005 13:38:21 -0500 From: "Margaret Wasserman" To: "'Wijnen, Bert \(Bert\)'" , "'Netconf \(E-mail\)'" Subject: RE: AD review for: Date: Wed, 23 Nov 2005 13:38:19 -0500 Message-ID: <000f01c5f05d$143e5020$5b03a8c0@instant802.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.2670 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15508A47C87@nl0006exch001u.nl.lucent.com> Thread-Index: AcXwVPd8ByW3XEZcQp+PFeP5/PFdTQAB5Yhw Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just FYI -- The latest SSH Draft (draft-ietf-netconf-ssh-05.txt) also has this problem (still includes "xml" in the capability strings). I'll also fix this along with any other LC issues. Margaret > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Wijnen, Bert (Bert) > Sent: Wednesday, November 23, 2005 12:34 PM > To: Netconf (E-mail) > Subject: AD review for: > > Just checking before I do IETF Last Call. > > Pls consider this early IETF Last Call comments. > Do not issue a new rev. I am requesting IETF Last Call now. > > On page 5... > I think you need to change: > A: urn:ietf:params:xml:ns:netconf:capability:startup:1.0 > into: > A: urn:ietf:params:netconf:capability:startup:1.0 > that is if you want to be insync with latest protocol draft, > in fact, according to youre Norm Reference [1] you synced up > with prot doc rev 7 while current one is 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: -- 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 Wed Nov 23 13:46:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eezd8-0004qw-2P for netconf-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:46:06 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10149 for ; Wed, 23 Nov 2005 13:45:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EezXW-0006SJ-82 for netconf-data@psg.com; Wed, 23 Nov 2005 18:40:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EezXV-0006Rx-MV for netconf@ops.ietf.org; Wed, 23 Nov 2005 18:40:17 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 23 Nov 2005 10:40:17 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jANIeHCJ016364; Wed, 23 Nov 2005 10:40:17 -0800 (PST) Received: from [212.254.247.5] (ams-clip-vpn-dhcp276.cisco.com [10.61.65.20]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jANImT8A003616; Wed, 23 Nov 2005 10:48:30 -0800 Message-ID: <4384B78B.50909@cisco.com> Date: Wed, 23 Nov 2005 19:40:11 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051025) MIME-Version: 1.0 To: Glenn Waters CC: "McDonald, Ira" , j.schoenwaelder@iu-bremen.de, Phil Shafer , Sharon Chisholm , netconf@ops.ietf.org Subject: Re: notification charter proposal References: <085091CB2CA14E4B8B163FFC37C84E9D073ED702@zcarhxm0.corp.nortel.com> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D073ED702@zcarhxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=448; t=1132771711; x=1133203911; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20notification=20charter=20proposal| From:Eliot=20Lear=20| Date:Wed,=2023=20Nov=202005=2019=3A40=3A11=20+0100| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=TSpPk7XR5/2u4Go8QqhNYMoJdZRWc/dOthmcWLjJ9rxoZdHHWp3OtQyIZcpLCG3EWpFoKrQC GbiEduC9vIOVztFE75hnneQiH7Ekxxe5dqr0WqwAD+OgRSAuZdacBWum+qysRoK7X6fgtF28t5u WniiWbENHCBkV5Z1y/1aSI8E= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Glenn Waters wrote: > Ahh, the challenges of multiple transports with differing features. So, > if we chose (b) then we don't *need* to do anything the protocol for > BEEP transport but we *need* to include something in the protocol for > SSH transport (and SOAP I just don't know). > > Of course Netconf is transport independent so if we chose (b) then we > *must* include in acks in the proto which means the BEEP transport will > have an extra ack. How about "The right tool for the right job?" For those who need this sort of thing, use BEEP. Eliot -- 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 Wed Nov 23 13:55:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eezlu-000284-Kh for netconf-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:55:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11079 for ; Wed, 23 Nov 2005 13:54:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eezfl-0007Jr-3M for netconf-data@psg.com; Wed, 23 Nov 2005 18:48:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.140.192.55] (helo=zrtps0kn.nortelnetworks.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eezfk-0007Jd-Eu for netconf@ops.ietf.org; Wed, 23 Nov 2005 18:48:48 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jANImW515812; Wed, 23 Nov 2005 13:48:32 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: notification charter proposal Date: Wed, 23 Nov 2005 13:47:37 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D073ED776@zcarhxm0.corp.nortel.com> Thread-Topic: notification charter proposal Thread-Index: AcXwXZkjA6qjbSI5TG2jn2IK80G0+AAAGKZA From: "Glenn Waters" To: "Eliot Lear" Cc: "McDonald, Ira" , , "Phil Shafer" , "Sharon Chisholm" , Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Elliot wrote: > How about "The right tool for the right job?" For those who need this > sort of thing, use BEEP. I'm not sure how to interpret your comment. If we decide (b) then we need to support acks in the notification protocol since ssh is the mandatory to implement transport. Cheers, /gww =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 Wed Nov 23 14:19:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef09c-0005Ta-Oi for netconf-archive@megatron.ietf.org; Wed, 23 Nov 2005 14:19:43 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13792 for ; Wed, 23 Nov 2005 14:19:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ef03b-0009N3-Lv for netconf-data@psg.com; Wed, 23 Nov 2005 19:13:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ef03b-0009Ms-6m for netconf@ops.ietf.org; Wed, 23 Nov 2005 19:13:27 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 23 Nov 2005 11:13:26 -0800 X-IronPort-AV: i="3.97,366,1125903600"; d="scan'208"; a="233725289:sNHT55165550" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jANJDNeS001048; Wed, 23 Nov 2005 11:13:24 -0800 (PST) Received: from [212.254.247.5] (ams-clip-vpn-dhcp276.cisco.com [10.61.65.20]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jANJLZ4r003965; Wed, 23 Nov 2005 11:21:36 -0800 Message-ID: <4384BF51.6020205@cisco.com> Date: Wed, 23 Nov 2005 20:13:21 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051025) MIME-Version: 1.0 To: Glenn Waters CC: "McDonald, Ira" , j.schoenwaelder@iu-bremen.de, Phil Shafer , Sharon Chisholm , netconf@ops.ietf.org Subject: Re: notification charter proposal References: <085091CB2CA14E4B8B163FFC37C84E9D073ED776@zcarhxm0.corp.nortel.com> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D073ED776@zcarhxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=226; t=1132773698; x=1133205898; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20notification=20charter=20proposal| From:Eliot=20Lear=20| Date:Wed,=2023=20Nov=202005=2020=3A13=3A21=20+0100| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=AWtEVA00LhQKQH4emI5UdZOXuDvIyOGy5L1ZsSYF58BHaX3mge5mWcaDDoVpWH34T3CgLtXv 38nNtT6aN9ljnGuUKCNBYoh5ZilB4liCUJ3VT8psL7evs8vEG+zb9A/WCLG+hqhG+uGuCA0mC+n dQfrMH2Dkf/GUurt/cYE/28g= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Glenn, What I'm saying is that while it is true that SSH is the "mandatory to implement", you only need to have application-level ACKs in the notification component if THEY are mandatory to implement. Otherwise you can leave it to the BEEP mapping and be done with it. Eliot -- 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 Wed Nov 23 15:33:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef1J6-0003mX-W7 for netconf-archive@megatron.ietf.org; Wed, 23 Nov 2005 15:33:33 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25216 for ; Wed, 23 Nov 2005 15:32:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ef1BN-000HH2-PR for netconf-data@psg.com; Wed, 23 Nov 2005 20:25:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ef1B1-000HEg-Q0 for netconf@ops.ietf.org; Wed, 23 Nov 2005 20:25:12 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 4F8B24C670; Wed, 23 Nov 2005 21:25:10 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 07081-02; Wed, 23 Nov 2005 21:25:09 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 027464C3B2; Wed, 23 Nov 2005 21:25:09 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id E87F352F5D4; Wed, 23 Nov 2005 21:25:06 +0100 (CET) Date: Wed, 23 Nov 2005 21:25:06 +0100 From: Juergen Schoenwaelder To: Eliot Lear Cc: Glenn Waters , "McDonald, Ira" , Phil Shafer , Sharon Chisholm , netconf@ops.ietf.org Subject: Re: notification charter proposal Message-ID: <20051123202506.GA3178@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Eliot Lear , Glenn Waters , "McDonald, Ira" , Phil Shafer , Sharon Chisholm , netconf@ops.ietf.org References: <085091CB2CA14E4B8B163FFC37C84E9D073ED776@zcarhxm0.corp.nortel.com> <4384BF51.6020205@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4384BF51.6020205@cisco.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk On Wed, Nov 23, 2005 at 08:13:21PM +0100, Eliot Lear wrote: > Glenn, > > What I'm saying is that while it is true that SSH is the "mandatory to > implement", you only need to have application-level ACKs in the > notification component if THEY are mandatory to implement. Otherwise > you can leave it to the BEEP mapping and be done with it. Again, lets first decide which semantics we need and then talk about the implementation. I personally have bad feelings if sematics associated with a netconf protocol operation are determined by the underlying transport. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Wed Nov 23 21:22:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef6kW-0000Mu-EL for netconf-archive@megatron.ietf.org; Wed, 23 Nov 2005 21:22:13 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00964 for ; Wed, 23 Nov 2005 21:21:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ef6dA-000JuN-4l for netconf-data@psg.com; Thu, 24 Nov 2005 02:14:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.53] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1Ef6d8-000JuB-SX for netconf@ops.ietf.org; Thu, 24 Nov 2005 02:14:35 +0000 Received: (qmail 27941 invoked from network); 24 Nov 2005 02:14:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.113 with SMTP; 24 Nov 2005 02:14:34 -0000 Message-ID: <43852207.2020703@andybierman.com> Date: Wed, 23 Nov 2005 18:14:31 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eliot Lear CC: Glenn Waters , "McDonald, Ira" , j.schoenwaelder@iu-bremen.de, Phil Shafer , Sharon Chisholm , netconf@ops.ietf.org Subject: Re: notification charter proposal References: <085091CB2CA14E4B8B163FFC37C84E9D073ED776@zcarhxm0.corp.nortel.com> <4384BF51.6020205@cisco.com> In-Reply-To: <4384BF51.6020205@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eliot Lear wrote: >Glenn, > >What I'm saying is that while it is true that SSH is the "mandatory to >implement", you only need to have application-level ACKs in the >notification component if THEY are mandatory to implement. Otherwise >you can leave it to the BEEP mapping and be done with it. > > I agree with Juergen on this one. I would like to make sure the mandatory transport (SSH) can be used for all the notification features defined. For the same reason, I don't think Rob's proposal to just use Syslog over BEEP will work. These ideas were floated around before SSH was picked instead of BEEP as expected at the time. However, I strongly agree with Rob wrt/ not inventing new info models but rather using the existing syslog info model to the greatest degree possible. The feature set at the protocol level should be the same. The transport implementation of that feature does not have to be the same of course. The thread on app-level ACKs is interesting, but keep in mind... If you make it complicated enough, then it ends up looking remarkably similar to our and , except in the other direction. (E.g. the agent issues an that says "here take this", and the manager send a that says or (too-big | did-not-grok, etc.) >Eliot > > 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 Wed Nov 23 21:50:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef7BZ-0006ul-Mu for netconf-archive@megatron.ietf.org; Wed, 23 Nov 2005 21:50:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03633 for ; Wed, 23 Nov 2005 21:49:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ef75Y-000M85-2k for netconf-data@psg.com; Thu, 24 Nov 2005 02:43:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.140.192.56] (helo=zrtps0kp.nortelnetworks.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ef75W-000M7t-8M for netconf@ops.ietf.org; Thu, 24 Nov 2005 02:43:54 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jAO2hGS09668; Wed, 23 Nov 2005 21:43:17 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: notification charter proposal Date: Wed, 23 Nov 2005 21:42:20 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D07446FD6@zcarhxm0.corp.nortel.com> Thread-Topic: notification charter proposal Thread-Index: AcXwnNM++7TzjUgxSJ+Er8gOKz4vSgAAk3yA From: "Glenn Waters" To: "Andy Bierman" , "Eliot Lear" Cc: "McDonald, Ira" , , "Phil Shafer" , "Sharon Chisholm" , Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Andy, I think you may have taken my comments a little out of context. Regardless I absolutely agree with you that the feature set at the protocol level must be the same no matter what the transport protocol is. Sorry if I wasn't clear. With respect to the ACK discussion there is something to be said for consistency. That said I would still like to understand what the possible value is of the (b) option. Question about ACK (assuming we do them) -- do people envision that if we ACK notifications then (1) are the notifications are serialized, i.e.: send notify, wait for ACK, send notify, wait for ACK, etc.; or, (2) are the notifications in parallel, i.e.: send some number of notifications and process the ACKs as they come in. I think (2) but wanted to clarify. Regards, /gww=20 > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Wednesday, November 23, 2005 21:15 > To: Eliot Lear > Cc: Waters, Glenn [CAR:IO47:EXCH]; McDonald, Ira; j.schoenwaelder@iu- > bremen.de; Phil Shafer; Chisholm, Sharon [CAR:5K50:EXCH]; > netconf@ops.ietf.org > Subject: Re: notification charter proposal >=20 > Eliot Lear wrote: >=20 > >Glenn, > > > >What I'm saying is that while it is true that SSH is the "mandatory to > >implement", you only need to have application-level ACKs in the > >notification component if THEY are mandatory to implement. Otherwise > >you can leave it to the BEEP mapping and be done with it. > > > > >=20 > I agree with Juergen on this one. > I would like to make sure the mandatory transport (SSH) > can be used for all the notification features defined. > For the same reason, I don't think Rob's proposal to just > use Syslog over BEEP will work. These ideas were floated > around before SSH was picked instead of BEEP as expected > at the time. However, I strongly agree with Rob wrt/ > not inventing new info models but rather using the > existing syslog info model to the greatest degree possible. >=20 > The feature set at the protocol level should be the same. > The transport implementation of that feature does not have > to be the same of course. >=20 > The thread on app-level ACKs is interesting, but keep in mind... > If you make it complicated enough, then it ends up looking > remarkably similar to our and , except > in the other direction. (E.g. the agent issues an > that says "here take this", and the manager send a > that says or (too-big | did-not-grok, etc.) >=20 > >Eliot > > > > >=20 > Andy >=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: From owner-netconf@ops.ietf.org Thu Nov 24 03:08:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfC9m-0001cq-MS for netconf-archive@megatron.ietf.org; Thu, 24 Nov 2005 03:08:38 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29053 for ; Thu, 24 Nov 2005 03:07:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfC0k-000Ky2-58 for netconf-data@psg.com; Thu, 24 Nov 2005 07:59:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfC0j-000Kxr-FW for netconf@ops.ietf.org; Thu, 24 Nov 2005 07:59:17 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 23 Nov 2005 23:59:17 -0800 X-IronPort-AV: i="3.97,370,1125903600"; d="scan'208"; a="369716375:sNHT25345964" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAO7xDeS027151; Wed, 23 Nov 2005 23:59:14 -0800 (PST) Received: from [212.254.247.6] (ams-clip-vpn-dhcp202.cisco.com [10.61.64.202]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jAO87Nv4008015; Thu, 24 Nov 2005 00:07:24 -0800 Message-ID: <438572CD.20602@cisco.com> Date: Thu, 24 Nov 2005 08:59:09 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051025) MIME-Version: 1.0 To: Andy Bierman CC: Glenn Waters , j.schoenwaelder@iu-bremen.de, Phil Shafer , Sharon Chisholm , netconf@ops.ietf.org Subject: Re: notification charter proposal References: <085091CB2CA14E4B8B163FFC37C84E9D073ED776@zcarhxm0.corp.nortel.com> <4384BF51.6020205@cisco.com> <43852207.2020703@andybierman.com> In-Reply-To: <43852207.2020703@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1546; t=1132819645; x=1133251845; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20notification=20charter=20proposal| From:Eliot=20Lear=20| Date:Thu,=2024=20Nov=202005=2008=3A59=3A09=20+0100| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=ZrBXhd37R6PRaJ9WUJylMWCqD1aT6KaIhfen5RPkmZaMq5mxndwUFsfhPdHWB4CbVIAFZmsy +/62MVhjq3UtpR5RVig7g1Qy0ES3gg8WCKWFIDHH0L8b2H4NC1Z6rm5aKDlSw+25An+L8w1L/8k gc67Hmrj09tQd9ByHopFgi8Q= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andy, I hope you're enjoying some decent Bird today in America and don't actually read this till later ;-) Please see below. Andy Bierman wrote: > I agree with Juergen on this one. I agree in part. I do not want the tail to wag the dog. Just because SSH or BEEP does or doesn't have a feature shouldn't dictate the approach to notifications (events, whatever..). > I would like to make sure the mandatory transport (SSH) > can be used for all the notification features defined. First, if the notification feature is not mandatory, you're probably adding extra unwanted hair. But if we go this route, let's make proper use of mapping mechanisms. If SSH needs to add an ACK that's already there for BEEP, don't make BEEP have a 2nd unnecessary ACK. Now putting the horse before the cart, I think we have a few problems in this space. First of all, there is the SYSLOG working group that is currently attempting to finalize a new specification that will include some amount of structured data. We must not simply duplicate their work in an incompatible way, and so I agree with you there. However, SYSLOG isn't much more than PRI+Date+host+text. There's a lot of room to do better than that. I think Sharon and crew should be thinking about one of two directions: - what to do with the structured text component contemplated by SYSLOG wg (and now's the time to talk to them - and I mean right now) - creating a second approach that is richer than what SYSLOG has. The good here is that event systems have been out there for a while, and so perhaps the time is ripe. The bad is that many have tried... So I don't know which approach is correct. Finally, I reiterate that events and notifications appear to be architecturally severable, and so I would like to understand why it is necessary for the netconf protocol to be extended beyond perhaps a capability referencing other work. Eliot -- 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 Nov 24 03:29:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfCUD-0000yo-US for netconf-archive@megatron.ietf.org; Thu, 24 Nov 2005 03:29:46 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01131 for ; Thu, 24 Nov 2005 03:29:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfCPy-000Mia-EE for netconf-data@psg.com; Thu, 24 Nov 2005 08:25:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfCPv-000Mhk-3w for netconf@ops.ietf.org; Thu, 24 Nov 2005 08:25:19 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 3EEB14C3B8; Thu, 24 Nov 2005 09:25:18 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 20114-03; Thu, 24 Nov 2005 09:25:16 +0100 (CET) Received: from zupanc.iuhb02.iu-bremen.de (unknown [212.201.48.211]) by hermes.iu-bremen.de (Postfix) with ESMTP id E17604C318; Thu, 24 Nov 2005 09:25:16 +0100 (CET) Received: by zupanc.iuhb02.iu-bremen.de (Postfix, from userid 501) id 6563A52F886; Thu, 24 Nov 2005 09:25:15 +0100 (CET) Date: Thu, 24 Nov 2005 09:25:15 +0100 From: Juergen Schoenwaelder To: Eliot Lear Cc: Andy Bierman , Glenn Waters , Phil Shafer , Sharon Chisholm , netconf@ops.ietf.org Subject: Re: notification charter proposal Message-ID: <20051124082515.GE3400@zupanc.iuhb02.iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Eliot Lear , Andy Bierman , Glenn Waters , Phil Shafer , Sharon Chisholm , netconf@ops.ietf.org References: <085091CB2CA14E4B8B163FFC37C84E9D073ED776@zcarhxm0.corp.nortel.com> <4384BF51.6020205@cisco.com> <43852207.2020703@andybierman.com> <438572CD.20602@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438572CD.20602@cisco.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk On Thu, Nov 24, 2005 at 08:59:09AM +0100, Eliot Lear wrote: > First, if the notification feature is not mandatory, you're probably > adding extra unwanted hair. But if we go this route, let's make proper > use of mapping mechanisms. If SSH needs to add an ACK that's already > there for BEEP, don't make BEEP have a 2nd unnecessary ACK. I guess the BEEP ACK acknowledges the BEEP message and does not ack that the netconf message was actually well formed and something that could be handed over to a netconf notification consumer. This might sound like splitting hairs - but I generally believe that a transport level ack is not the same as a netconf level ack, unless the transport actually implements something like c). Since you know BEEP much better than I do, you can probably point me to the section where the BEEP spec says it actually does have the ack semantics we are talking about here (ie, the ack acknowledges the upper layer correctness of the received BEEP message). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Nov 24 04:59:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfDtV-0000QH-Lh for netconf-archive@megatron.ietf.org; Thu, 24 Nov 2005 04:59:57 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09644 for ; Thu, 24 Nov 2005 04:59:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfDmc-0003xw-Px for netconf-data@psg.com; Thu, 24 Nov 2005 09:52:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfDmc-0003xk-BB for netconf@ops.ietf.org; Thu, 24 Nov 2005 09:52:50 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 24 Nov 2005 01:52:50 -0800 X-IronPort-AV: i="3.97,370,1125903600"; d="scan'208"; a="678221246:sNHT22823184" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAO9qleS004536; Thu, 24 Nov 2005 01:52:47 -0800 (PST) Received: from [212.254.247.6] (ams-clip-vpn-dhcp4264.cisco.com [10.61.80.167]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jAOA0vCF008480; Thu, 24 Nov 2005 02:00:57 -0800 Message-ID: <43858D6C.8080406@cisco.com> Date: Thu, 24 Nov 2005 10:52:44 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051025) MIME-Version: 1.0 To: Eliot Lear , Andy Bierman , Glenn Waters , Phil Shafer , Sharon Chisholm , netconf@ops.ietf.org Subject: Re: notification charter proposal References: <085091CB2CA14E4B8B163FFC37C84E9D073ED776@zcarhxm0.corp.nortel.com> <4384BF51.6020205@cisco.com> <43852207.2020703@andybierman.com> <438572CD.20602@cisco.com> <20051124082515.GE3400@zupanc.iuhb02.iu-bremen.de> In-Reply-To: <20051124082515.GE3400@zupanc.iuhb02.iu-bremen.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=107; t=1132826459; x=1133258659; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20notification=20charter=20proposal| From:Eliot=20Lear=20| Date:Thu,=2024=20Nov=202005=2010=3A52=3A44=20+0100| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=l6vUbZH/78z9DZE033l4GAS1xZcmGfVQHtBGEIMeqxJh6Qa/ex95wexUMtRDg/mD4Wx1W+bm /ZUOW4iaMwO1EmlzFySk48J364svkcf7IEaFzEHqrhQ8j22gMKh0hp3DUGvAzju5UozcasfPybV laQIT18XspgueHzYEZRIkltE= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If an implementation wants this sort of behavior limit a single notification to a single MSG and expect a single RPY in response. -- 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 Nov 24 07:04:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfFqE-0002d3-6S for netconf-archive@megatron.ietf.org; Thu, 24 Nov 2005 07:04:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20996 for ; Thu, 24 Nov 2005 07:04:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfFhR-000CAl-Rc for netconf-data@psg.com; Thu, 24 Nov 2005 11:55:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfFhR-000CAL-3m for netconf@ops.ietf.org; Thu, 24 Nov 2005 11:55:37 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jAOBtPmN028959; Thu, 24 Nov 2005 05:55:25 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 24 Nov 2005 12:54:50 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508A47EAA@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Margaret Wasserman , "'Netconf (E-mail)'" Subject: RE: AD review for: draft-ietf-netconf-ssh-05.txt Date: Thu, 24 Nov 2005 12:55:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-netconf@ops.ietf.org Precedence: bulk [ changed subject line ] Mmm looks like I indeed missed that. I guess you mean the urn:ietf:params:xml:ns:netconf:base:1.0#startup on page 5 Bert > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Wednesday, November 23, 2005 19:38 > To: 'Wijnen, Bert (Bert)'; 'Netconf (E-mail)' > Subject: RE: AD review for: draft-ietf-netconf-ssh-05.txt > > > > > Just FYI -- > > The latest SSH Draft (draft-ietf-netconf-ssh-05.txt) also has > this problem > (still includes "xml" in the capability strings). I'll also > fix this along > with any other LC issues. > > Margaret > > > -----Original Message----- > > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On > > Behalf Of Wijnen, Bert (Bert) > > Sent: Wednesday, November 23, 2005 12:34 PM > > To: Netconf (E-mail) > > Subject: AD review for: > > > > Just checking before I do IETF Last Call. > > > > Pls consider this early IETF Last Call comments. > > Do not issue a new rev. I am requesting IETF Last Call now. > > > > On page 5... > > I think you need to change: > > A: urn:ietf:params:xml:ns:netconf:capability:startup:1.0 > > into: > > A: urn:ietf:params:netconf:capability:startup:1.0 > > that is if you want to be insync with latest protocol draft, > > in fact, according to youre Norm Reference [1] you synced up > > with prot doc rev 7 while current one is 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: > -- 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 Nov 24 10:32:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfJ4z-00018T-Ic for netconf-archive@megatron.ietf.org; Thu, 24 Nov 2005 10:32:09 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17165 for ; Thu, 24 Nov 2005 10:31:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfIwn-0001hb-KM for netconf-data@psg.com; Thu, 24 Nov 2005 15:23:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfIwl-0001hE-Qn for netconf@ops.ietf.org; Thu, 24 Nov 2005 15:23:40 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jAOFNZD24783 for ; Thu, 24 Nov 2005 10:23:35 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: notification charter proposal Date: Thu, 24 Nov 2005 10:23:04 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405DE70A8@zcarhxm2.corp.nortel.com> Thread-Topic: notification charter proposal Thread-Index: AcXvcZD47iElq/qOQWORABlFxJN59gBmNwxw From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi The only interest I saw historically in informs were from people who were disappointed we didn't run over TCP. After some investigation, people generally chose other means to maintain confidence that they were not loosing information. I just didn't see informs used in practice.=20 Given we now run over TCP, I have difficulty seeing people using acknowledged notifications in practice. The solution could be defined, but I don't really know if there a lot of value in doing so. Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 Sent: Tuesday, November 22, 2005 9:32 AM To: Waters, Glenn [CAR:IO47:EXCH] Cc: Chisholm, Sharon [CAR:5K50:EXCH]; netconf@ops.ietf.org Subject: Re: notification charter proposal On Tue, Nov 22, 2005 at 09:00:20AM -0500, Glenn Waters wrote: > > b) The notification sender sends a notification and gets a confirmation > > that the notification was understood to the extend that it could be > > handed over to an entity dealing with notifications. (This is what > > SNMP notifications actually do.) >=20 > I don't think that there is enough value in sending a response in this > case since there is little recourse the sender can take to correct the > issue. There is the possibility the sender could reduce the message=20 > size but that can be handled in other ways (such as the receiver=20 > reconfiguring the max size the sender should send). I can't think of=20 > what else a sender would possibly do with a response. Maybe it would=20 > help to identify those items to help decide if a response would be=20 > useful. Knowledge of the fact that you were not understood can be very useful, even if you do not know how to make yourself understood. You are arguing from a very narrow protocol centric perspective and=20 I agree that from this protocol centric perspective there is hardly something you can do. However, if you take a more system wide perspective, then I think one can easily make a case for b) and even for c). Note: I am not against a) nor am I against b) and c) - it is just important for me that once we talk about adding notifications, we better be clear what their semantics are and which role they can play in a systems view. /js PS: There are also strong ties here to notification logging (see the NOTIFICATION-LOG-MIB produced by the DISMAN WG). The information whether a notification was "understood" can actually be used to decide what remains in a log and what can be purged. Without such information, the notification originator actually has to log=20 everything (and maybe rely on the receiver to clear log entries). --=20 Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Nov 24 11:42:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfKAe-0001bg-L2 for netconf-archive@megatron.ietf.org; Thu, 24 Nov 2005 11:42:11 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25431 for ; Thu, 24 Nov 2005 11:41:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfK3S-0007j9-PY for netconf-data@psg.com; Thu, 24 Nov 2005 16:34:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1EfK3R-0007iq-Uo for netconf@ops.ietf.org; Thu, 24 Nov 2005 16:34:38 +0000 Received: (qmail 7094 invoked by uid 78); 24 Nov 2005 16:34:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.58 with SMTP; 24 Nov 2005 16:34:37 -0000 Message-ID: <4385EB94.9030303@andybierman.com> Date: Thu, 24 Nov 2005 08:34:28 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: notification charter proposal References: <713043CE8B8E1348AF3C546DBE02C1B405DE70A8@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B405DE70A8@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sharon Chisholm wrote: >hi > >The only interest I saw historically in informs were from people who >were disappointed we didn't run over TCP. After some investigation, >people generally chose other means to maintain confidence that they were >not loosing information. I just didn't see informs used in practice. > >Given we now run over TCP, I have difficulty seeing people using >acknowledged notifications in practice. The solution could be defined, >but I don't really know if there a lot of value in doing so. > > > This is what I was trying to say (kind of). We could define a mechanism so robust, it would be a reverse-RPC. But what's good for serialized work-flow oriented data transfer isn't so good for exception-based "get rid of it and get back to work" kind of things. IMO, a transport-level ACK that the bytes got through is the most we would need, and unless we change transports, this is what TCP gives you whether you want it or not. >Sharon > > Andy >-----Original Message----- >From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] >Sent: Tuesday, November 22, 2005 9:32 AM >To: Waters, Glenn [CAR:IO47:EXCH] >Cc: Chisholm, Sharon [CAR:5K50:EXCH]; netconf@ops.ietf.org >Subject: Re: notification charter proposal > > >On Tue, Nov 22, 2005 at 09:00:20AM -0500, Glenn Waters wrote: > > > >>>b) The notification sender sends a notification and gets a >>> >>> >confirmation > > >>> that the notification was understood to the extend that it could >>> >>> >be > > >>> handed over to an entity dealing with notifications. (This is >>> >>> >what > > >>> SNMP notifications actually do.) >>> >>> >>I don't think that there is enough value in sending a response in this >> >> > > > >>case since there is little recourse the sender can take to correct the >> >> > > > >>issue. There is the possibility the sender could reduce the message >>size but that can be handled in other ways (such as the receiver >>reconfiguring the max size the sender should send). I can't think of >>what else a sender would possibly do with a response. Maybe it would >>help to identify those items to help decide if a response would be >>useful. >> >> > >Knowledge of the fact that you were not understood can be very useful, >even if you do not know how to make yourself understood. > >You are arguing from a very narrow protocol centric perspective and >I agree that from this protocol centric perspective there is hardly >something you can do. However, if you take a more system wide >perspective, then I think one can easily make a case for b) and even for >c). > >Note: I am not against a) nor am I against b) and c) - it is just >important for me that once we talk about adding notifications, we better >be clear what their semantics are and which role they can play in a >systems view. > >/js > >PS: There are also strong ties here to notification logging (see the > NOTIFICATION-LOG-MIB produced by the DISMAN WG). The information > whether a notification was "understood" can actually be used to > decide what remains in a log and what can be purged. Without such > information, the notification originator actually has to log > everything (and maybe rely on the receiver to clear log entries). > > > -- 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 Nov 24 16:04:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfOGT-0007WG-Dq for netconf-archive@megatron.ietf.org; Thu, 24 Nov 2005 16:04:21 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24696 for ; Thu, 24 Nov 2005 16:03:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfO8K-00022G-2Y for netconf-data@psg.com; Thu, 24 Nov 2005 20:55:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfO8J-00021y-5A for netconf@ops.ietf.org; Thu, 24 Nov 2005 20:55:55 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id jAOKtrEv000890 for ; Thu, 24 Nov 2005 12:55:53 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 24 Nov 2005 12:58:10 -0800 Message-ID: From: "McDonald, Ira" To: netconf@ops.ietf.org Subject: RE: notification charter proposal Date: Thu, 24 Nov 2005 12:58:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, As Juergen Schoenwaelder just pointed out - a transport layer ACK does NOT have the same semantics as an upper layer ACK that indicates receipt of a well-formed XML message. Confusing the two is not helpful - NetConf is supposed to behave the same over any transport. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Sharon Chisholm > Sent: Thursday, November 24, 2005 10:23 AM > To: netconf@ops.ietf.org > Subject: RE: notification charter proposal > > > hi > > The only interest I saw historically in informs were from people who > were disappointed we didn't run over TCP. After some investigation, > people generally chose other means to maintain confidence > that they were > not loosing information. I just didn't see informs used in practice. > > Given we now run over TCP, I have difficulty seeing people using > acknowledged notifications in practice. The solution could be defined, > but I don't really know if there a lot of value in doing so. > > Sharon > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Tuesday, November 22, 2005 9:32 AM > To: Waters, Glenn [CAR:IO47:EXCH] > Cc: Chisholm, Sharon [CAR:5K50:EXCH]; netconf@ops.ietf.org > Subject: Re: notification charter proposal > > > On Tue, Nov 22, 2005 at 09:00:20AM -0500, Glenn Waters wrote: > > > > b) The notification sender sends a notification and gets a > confirmation > > > that the notification was understood to the extend > that it could > be > > > handed over to an entity dealing with notifications. (This is > what > > > SNMP notifications actually do.) > > > > I don't think that there is enough value in sending a > response in this > > > case since there is little recourse the sender can take to > correct the > > > issue. There is the possibility the sender could reduce the message > > size but that can be handled in other ways (such as the receiver > > reconfiguring the max size the sender should send). I can't > think of > > what else a sender would possibly do with a response. Maybe > it would > > help to identify those items to help decide if a response would be > > useful. > > Knowledge of the fact that you were not understood can be very useful, > even if you do not know how to make yourself understood. > > You are arguing from a very narrow protocol centric perspective and > I agree that from this protocol centric perspective there is hardly > something you can do. However, if you take a more system wide > perspective, then I think one can easily make a case for b) > and even for > c). > > Note: I am not against a) nor am I against b) and c) - it is just > important for me that once we talk about adding > notifications, we better > be clear what their semantics are and which role they can play in a > systems view. > > /js > > PS: There are also strong ties here to notification logging (see the > NOTIFICATION-LOG-MIB produced by the DISMAN WG). The information > whether a notification was "understood" can actually be used to > decide what remains in a log and what can be purged. Without such > information, the notification originator actually has to log > everything (and maybe rely on the receiver to clear log entries). > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, > Germany > > > -- > 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 Thu Nov 24 20:28:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfSOC-0006GU-UV for netconf-archive@megatron.ietf.org; Thu, 24 Nov 2005 20:28:37 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22668 for ; Thu, 24 Nov 2005 20:27:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfSFX-000Nxa-Rk for netconf-data@psg.com; Fri, 25 Nov 2005 01:19:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.140.192.56] (helo=zrtps0kp.nortelnetworks.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfSFS-000Nv6-5H for netconf@ops.ietf.org; Fri, 25 Nov 2005 01:19:34 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jAP1JVe10378 for ; Thu, 24 Nov 2005 20:19:31 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: notification charter proposal Date: Thu, 24 Nov 2005 20:19:29 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405DE7778@zcarhxm2.corp.nortel.com> Thread-Topic: notification charter proposal Thread-Index: AcXxOtLkUs38Qg67Ruy6csiYNQCC1QAIwfFA From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi No, they are not the same, but the transport layer one seems to be sufficient from what I have seen. I suggest we don't do anything to preclude the later addition of an application level acknowledgements, but that we don't provide one now. The design in the current draft does this. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of McDonald, Ira Sent: Thursday, November 24, 2005 3:58 PM To: netconf@ops.ietf.org Subject: RE: notification charter proposal Hi, As Juergen Schoenwaelder just pointed out - a transport layer ACK does NOT have the same semantics as an upper layer ACK that indicates receipt of a well-formed XML message. Confusing the two is not helpful - NetConf is supposed to behave the same over any transport. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Sharon Chisholm > Sent: Thursday, November 24, 2005 10:23 AM > To: netconf@ops.ietf.org > Subject: RE: notification charter proposal >=20 >=20 > hi >=20 > The only interest I saw historically in informs were from people who=20 > were disappointed we didn't run over TCP. After some investigation,=20 > people generally chose other means to maintain confidence that they=20 > were not loosing information. I just didn't see informs used in=20 > practice. >=20 > Given we now run over TCP, I have difficulty seeing people using=20 > acknowledged notifications in practice. The solution could be defined, > but I don't really know if there a lot of value in doing so. >=20 > Sharon >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Tuesday, November 22, 2005 9:32 AM > To: Waters, Glenn [CAR:IO47:EXCH] > Cc: Chisholm, Sharon [CAR:5K50:EXCH]; netconf@ops.ietf.org > Subject: Re: notification charter proposal >=20 >=20 > On Tue, Nov 22, 2005 at 09:00:20AM -0500, Glenn Waters wrote: >=20 > > > b) The notification sender sends a notification and gets a > confirmation > > > that the notification was understood to the extend > that it could > be > > > handed over to an entity dealing with notifications. (This is > what > > > SNMP notifications actually do.) > >=20 > > I don't think that there is enough value in sending a > response in this >=20 > > case since there is little recourse the sender can take to > correct the >=20 > > issue. There is the possibility the sender could reduce the message > > size but that can be handled in other ways (such as the receiver=20 > > reconfiguring the max size the sender should send). I can't=20 > think of > > what else a sender would possibly do with a response. Maybe > it would > > help to identify those items to help decide if a response would be > > useful. >=20 > Knowledge of the fact that you were not understood can be very useful, > even if you do not know how to make yourself understood. >=20 > You are arguing from a very narrow protocol centric perspective and > I agree that from this protocol centric perspective there is hardly > something you can do. However, if you take a more system wide > perspective, then I think one can easily make a case for b)=20 > and even for > c). >=20 > Note: I am not against a) nor am I against b) and c) - it is just=20 > important for me that once we talk about adding notifications, we=20 > better be clear what their semantics are and which role they can play=20 > in a systems view. >=20 > /js >=20 > PS: There are also strong ties here to notification logging (see the > NOTIFICATION-LOG-MIB produced by the DISMAN WG). The information > whether a notification was "understood" can actually be used to > decide what remains in a log and what can be purged. Without such > information, the notification originator actually has to log=20 > everything (and maybe rely on the receiver to clear log entries). >=20 > --=20 > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, > Germany >=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 Thu Nov 24 23:15:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfUzS-0008RP-Du for netconf-archive@megatron.ietf.org; Thu, 24 Nov 2005 23:15:19 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05238 for ; Thu, 24 Nov 2005 23:14:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfUsJ-000B8y-1i for netconf-data@psg.com; Fri, 25 Nov 2005 04:07:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00, ROUND_THE_WORLD_LOCAL autolearn=no version=3.1.0 Received: from [69.59.170.132] (helo=s4.qlc.co.in) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfUsH-000B8l-TO for netconf@ops.ietf.org; Fri, 25 Nov 2005 04:07:49 +0000 Received: from mail2.qlc.co.in (mail2.qlc.co.in [203.199.124.121]) by s4.qlc.co.in (Postfix) with ESMTP id 53A363A4827 for ; Fri, 25 Nov 2005 09:35:07 +0530 (IST) Received: from wsspl.com (unknown [219.91.145.91]) by mail2.qlc.co.in (Postfix) with ESMTP id CB0731C004 for ; Fri, 25 Nov 2005 09:14:37 +0530 (IST) Received: from 172.16.10.3 [172.16.10.3] by paroksha.wsspl.com (1.61/SMTPD) at Fri, 25 Nov 05 09:38:49 India Received: by medha.wsspl.com with Internet Mail Service (5.5.2656.59) id ; Fri, 25 Nov 2005 09:37:20 +0530 Message-ID: <30BFDEA66FF4D41191EB00D0B765BC6F012B2FA0@medha.wsspl.com> X-Envelope-From: rkayyar@WSSPL.com From: Rathnakumar Kayyar To: netconf@ops.ietf.org Subject: RE: notification charter proposal Date: Fri, 25 Nov 2005 09:37:17 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Gateway: pop@GIFT-Ver. 6.0 for Exchange (006916.69) Sender: owner-netconf@ops.ietf.org Precedence: bulk A note on the application. CMISE/CMIP/GDMO's "confirmed notification" provides the means of sending a confirmation from the application level. Though it is the application's responsibility to confirm, the protocol and the data model provide the support. Usage wise, I have seen mobile switches re-sending the CDR via a CMIP notification, re-attempting if the ACK doesn't come, and finally logging it to the local disk, to be retrieved later via tftp by the billing application. Rathnakumar Kayyar [Disclaimer: I joined the group yesterday, so igonre this if this is beyond the scope of the discussion -:) -----Original Message----- From: Sharon Chisholm [mailto:schishol@nortel.com] Sent: Friday, November 25, 2005 6:49 AM To: netconf@ops.ietf.org Subject: RE: notification charter proposal hi No, they are not the same, but the transport layer one seems to be sufficient from what I have seen. I suggest we don't do anything to preclude the later addition of an application level acknowledgements, but that we don't provide one now. The design in the current draft does this. Sharon -----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of McDonald, Ira Sent: Thursday, November 24, 2005 3:58 PM To: netconf@ops.ietf.org Subject: RE: notification charter proposal Hi, As Juergen Schoenwaelder just pointed out - a transport layer ACK does NOT have the same semantics as an upper layer ACK that indicates receipt of a well-formed XML message. Confusing the two is not helpful - NetConf is supposed to behave the same over any transport. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Sharon Chisholm > Sent: Thursday, November 24, 2005 10:23 AM > To: netconf@ops.ietf.org > Subject: RE: notification charter proposal > > > hi > > The only interest I saw historically in informs were from people who > were disappointed we didn't run over TCP. After some investigation, > people generally chose other means to maintain confidence that they > were not loosing information. I just didn't see informs used in > practice. > > Given we now run over TCP, I have difficulty seeing people using > acknowledged notifications in practice. The solution could be defined, > but I don't really know if there a lot of value in doing so. > > Sharon > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Tuesday, November 22, 2005 9:32 AM > To: Waters, Glenn [CAR:IO47:EXCH] > Cc: Chisholm, Sharon [CAR:5K50:EXCH]; netconf@ops.ietf.org > Subject: Re: notification charter proposal > > > On Tue, Nov 22, 2005 at 09:00:20AM -0500, Glenn Waters wrote: > > > > b) The notification sender sends a notification and gets a > confirmation > > > that the notification was understood to the extend > that it could > be > > > handed over to an entity dealing with notifications. (This is > what > > > SNMP notifications actually do.) > > > > I don't think that there is enough value in sending a > response in this > > > case since there is little recourse the sender can take to > correct the > > > issue. There is the possibility the sender could reduce the message > > size but that can be handled in other ways (such as the receiver > > reconfiguring the max size the sender should send). I can't > think of > > what else a sender would possibly do with a response. Maybe > it would > > help to identify those items to help decide if a response would be > > useful. > > Knowledge of the fact that you were not understood can be very useful, > even if you do not know how to make yourself understood. > > You are arguing from a very narrow protocol centric perspective and > I agree that from this protocol centric perspective there is hardly > something you can do. However, if you take a more system wide > perspective, then I think one can easily make a case for b) > and even for > c). > > Note: I am not against a) nor am I against b) and c) - it is just > important for me that once we talk about adding notifications, we > better be clear what their semantics are and which role they can play > in a systems view. > > /js > > PS: There are also strong ties here to notification logging (see the > NOTIFICATION-LOG-MIB produced by the DISMAN WG). The information > whether a notification was "understood" can actually be used to > decide what remains in a log and what can be purged. Without such > information, the notification originator actually has to log > everything (and maybe rely on the receiver to clear log entries). > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, > Germany > > > -- > 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: -- 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 Nov 25 02:09:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfXi9-0003yD-E1 for netconf-archive@megatron.ietf.org; Fri, 25 Nov 2005 02:09:33 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19191 for ; Fri, 25 Nov 2005 02:08:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfXUz-000Pln-1W for netconf-data@psg.com; Fri, 25 Nov 2005 06:55:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfXUx-000PlS-HP for netconf@ops.ietf.org; Fri, 25 Nov 2005 06:55:56 +0000 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0FDA1FB6 for ; Fri, 25 Nov 2005 07:55:54 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Nov 2005 07:55:29 +0100 Received: from esealmw103.eemea.ericsson.se ([153.88.200.66]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Nov 2005 07:55:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F18D.382C182A" Subject: NETCONF inconsistency in get-config/source Date: Fri, 25 Nov 2005 07:55:28 +0100 Message-ID: <94B96B3383630441B365F7649034034801490FD7@esealmw103.eemea.ericsson.se> Thread-Topic: NETCONF inconsistency in get-config/source thread-index: AcXxjTginvGJ4iMFSjKUh5uXwqGF6w== From: "Stig Solberg (LN/EAB)" To: X-OriginalArrivalTime: 25 Nov 2005 06:55:29.0105 (UTC) FILETIME=[38880C10:01C5F18D] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F18D.382C182A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, there seems to be an inconsistency in how the source element is = specified for get-config in text (page 31) and how it it is specified in the NETCONF schema. In the text section it is defined as follows. That is, it seems to be an = optional=20 element source: Name of the configuration datastore being queried, such as . If this element is unspecified, the configuration is used. But in it NETCONF schema it is specified as being an mandatory element = since minOccurs by default have the value 1: Regards, Stig Solberg Software Engineer Voice: +46 (0)31 747 3251 Ericsson AB Fax : +46 (0)31 747 6033 G=F6teborg, Sweden Email: stig.solberg@ericsson.com ------_=_NextPart_001_01C5F18D.382C182A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable NETCONF inconsistency in get-config/source

Hi,
there seems to be an inconsistency in = how the source element is specified for get-config
in text (page 31) and how it it is = specified in the NETCONF schema.
In the text section it is defined as = follows. That is, it seems to be an optional
element
     = source:

         Name of = the configuration datastore being queried, such as
         = <running/>.  If this element is unspecified, the = <running/>
         = configuration is used.

But in it NETCONF schema it is = specified as being an mandatory element since
minOccurs by default have the value = 1:
     = <xs:complexType name=3D"getConfigType">
       = <xs:complexContent>
         = <xs:extension base=3D"rpcOperationType">
         &nbs= p; <xs:sequence>
         &nbs= p;   <xs:element name=3D"source"
         &nbs= p;            = ;   type=3D"getConfigSourceType"/>
         &nbs= p;   <xs:element name=3D"filter"
         &nbs= p;            = ;   type=3D"filterInlineType" = minOccurs=3D"0"/>
         &nbs= p; </xs:sequence>
<cut>

Regards,
Stig Solberg
Software = Engineer           = ;   Voice: +46 (0)31 747 3251
Ericsson = AB               &n= bsp;    Fax  : +46 (0)31 747 6033
G=F6teborg, Sweden               = Email: stig.solberg@ericsson.com



------_=_NextPart_001_01C5F18D.382C182A-- -- 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 Nov 25 03:23:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfYrR-0005na-PB for netconf-archive@megatron.ietf.org; Fri, 25 Nov 2005 03:23:15 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25325 for ; Fri, 25 Nov 2005 03:22:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfYkI-0006UR-7z for netconf-data@psg.com; Fri, 25 Nov 2005 08:15:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfYkF-0006UC-OE for netconf@ops.ietf.org; Fri, 25 Nov 2005 08:15:47 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 25 Nov 2005 00:15:48 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jAP8Fh6a013050; Fri, 25 Nov 2005 00:15:43 -0800 (PST) Received: from [212.254.247.6] (ams-clip-vpn-dhcp4411.cisco.com [10.61.81.58]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jAP8NoTF013496; Fri, 25 Nov 2005 00:23:51 -0800 Message-ID: <4386C82C.2010503@cisco.com> Date: Fri, 25 Nov 2005 09:15:40 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051025) MIME-Version: 1.0 To: "McDonald, Ira" CC: netconf@ops.ietf.org Subject: Re: notification charter proposal References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1460; t=1132907031; x=1133339231; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20notification=20charter=20proposal| From:Eliot=20Lear=20| Date:Fri,=2025=20Nov=202005=2009=3A15=3A40=20+0100| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=YUywzEL9arw/viX2sEI2UipoWc6JGipboSqZMAWow+0j/P7G9pDbq7o5j7UhhEOYSiJy+9FP 1C63vDRGH8aE8ON7O29sYdOh9U+ZALkEm/EeIZ9RLPLRzA9TleDgSM8ofyJzz0Wh5wDQbWZgeUh Lcvc0Zux0E5ubJKv7dkL+uNg= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit McDonald, Ira wrote: > Hi, > > As Juergen Schoenwaelder just pointed out - a transport layer > ACK does NOT have the same semantics as an upper layer ACK > that indicates receipt of a well-formed XML message. What is of particular concern is the way things are going in ISMS, where because of the existing ASIs and elements of procedure a question came up over how to signal back to the upper layers when a TCP connection has failed. One solution was to simply ignore the problem and let the upper layer deal with the problem as if the transport WERE unreliable. I don't like that approach because it doesn't properly take advantage of TCP's ability to alert the application to a network problem. Related- we are currently in a bit of a scrum with ATIS TMOC over IPFIX about application layer acknowledgments. There they want 100% reliability "from disk to disk". That means that even a TCP ACK is not sufficient because the recipient stack will have ACKed probably several ms before that point. Here is the question: what level of reliability is necessary for the applications we have in mind? The above example is for accounting where arguably money is involved. Are these notifications going to be used to derive a revenue event (SLA management, for instance) such that if a recipient crashes and the event is lost after having been acknowledged somebody would be upset? I don't envision that. Therefore I wouldn't include it. However, if somebody wants it they can still have it by using BEEP. All of this having been said... > > Confusing the two is not helpful - NetConf is supposed to > behave the same over any transport. If NETCONF is to behave the same over any transport then why have more than one? Why are we going through a last call for THREE transports? Eliot -- 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 Nov 25 03:28:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfYwO-0006rA-AR for netconf-archive@megatron.ietf.org; Fri, 25 Nov 2005 03:28:20 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25809 for ; Fri, 25 Nov 2005 03:27:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfYr8-00076T-4C for netconf-data@psg.com; Fri, 25 Nov 2005 08:22:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfYr6-000767-R1 for netconf@ops.ietf.org; Fri, 25 Nov 2005 08:22:53 +0000 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DBDAE4F0004 for ; Fri, 25 Nov 2005 09:22:51 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Nov 2005 09:22:32 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Nov 2005 09:22:31 +0100 Message-ID: <4386C9C2.2070005@ericsson.com> Date: Fri, 25 Nov 2005 09:22:26 +0100 From: Balazs Lengyel User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: netconf@ops.ietf.org Subject: Re: Size matters was Re: notification charter proposal References: <6E21698722408147BEA594E073E2B0AB0105B6A7@xmb-sjc-223.amer.cisco.com> In-Reply-To: <6E21698722408147BEA594E073E2B0AB0105B6A7@xmb-sjc-223.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Nov 2005 08:22:31.0971 (UTC) FILETIME=[619A2730:01C5F199] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Please dont set a max message size generally for netconf !!! For me one attractive usage of netconf would be to retrieve the complete configuration of a node. If we set a mandatory max-size for all netconf messages (as opposed to setting it for notifications only) this usage would become impossible. For big nodes it is anyone's guess what the size of a full configuration can be. We have nodes that contain the data of 10 million subscribers. Balazs Lengyel Ericsson Hungary Ltd. Hector Trevino (htrevino) wrote: > > I agree that this is part of the protocol definition but I see it as > outside the scope of the charter definition. I'd assume none of this > will be included in the charter. > > > I don't think the spec should set a hard limit on the max message size. > I agree w/Juergen about not limiting the protocol but rather allowing > implementations to advertise their max message sizes (if one is set). It > may be better to say something like app layer message segmentation is > not allowed. But recommendations/guidelines for max message sizes should > be provided in the spec. > > Hector > > > > > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Andy Bierman > Sent: Tuesday, November 22, 2005 4:01 PM > To: Tom Petch > Cc: netconf@ops.ietf.org > Subject: Re: Size matters was Re: notification charter proposal > > Tom Petch wrote: > > >> >>Tom Petch >>----- Original Message ----- >>From: "Andy Bierman" >>To: >>Cc: "Tom Petch" ; >>Sent: Tuesday, November 22, 2005 4:41 PM >>Subject: Re: notification charter proposal > > >> >> >> >>>That would be fine with me. >>>I brought up the issue because the problem is obviously worse for >>>notifications than RPCs, because the lack of an application layer ACK >>>(which effectively is). >>> >>>The reason for setting a minimum is to allow NMS developers to code to > > >>>some reasonable minimum. The market will help keep things somewhat >>>reasonable, but we could see a range from 1500 to 64K as the minimum. > > >>>Is that OK? >>> >>>Andy >>> >>> >>> >> >>I raised size because there are references appearing on the list >>calling for something syslog-like and size has been an issue with >>syslog that has not been satisfactorily resolved. syslog unearthed two > > >>contrasting viewpoints, one that messages should not exceed 2k or even >>1k, the other that 64k should be supported (for at least one > > application). > >>Netconf is more virgin territory than syslog is but I do believe is >>setting a Maximum size, at least to start with; but I do not see this >>as anything to do with the charter:-). >> >> > > > This is part of protocol syntax and semantics. > > IMO, the best approach is to have the NC peer advertise its > max-message-size. The number should be an PositiveInteger, so that > would set a theoretical max-message-size of 4G-1 bytes. > > > A separate issue is whether there is a minimum an NC peer can set this > parameter to, somewhat higher than zero. I don't see any consensus yet > on how much higher to set the minimum. > > > Another important issue: Can an NC peer (optionally?) send its > max-message-size in the exchange? This doesn't mean the other > NC peer has to do anything with the value, it just provides a good guess > at the number instead of trying > various message sizes to see what breaks. Advertising a > max-message-size doesn't mean you won't get messages greater than that > size. > > > >>Tom Petch >> >> >> >> > > > 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: -- 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 Nov 25 04:06:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfZXA-0004Ar-SA for netconf-archive@megatron.ietf.org; Fri, 25 Nov 2005 04:06:20 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28858 for ; Fri, 25 Nov 2005 04:05:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfZR4-000ALI-Bk for netconf-data@psg.com; Fri, 25 Nov 2005 09:00:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfZR3-000AKe-Ie for netconf@ops.ietf.org; Fri, 25 Nov 2005 09:00:01 +0000 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7755D4F0016 for ; Fri, 25 Nov 2005 09:33:56 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Nov 2005 09:33:37 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Nov 2005 09:33:36 +0100 Message-ID: <4386CC5B.7060303@ericsson.com> Date: Fri, 25 Nov 2005 09:33:31 +0100 From: Balazs Lengyel User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: notification charter proposal References: <085091CB2CA14E4B8B163FFC37C84E9D073ED776@zcarhxm0.corp.nortel.com> <4384BF51.6020205@cisco.com> <20051123202506.GA3178@boskop.local> In-Reply-To: <20051123202506.GA3178@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Nov 2005 08:33:36.0909 (UTC) FILETIME=[EDEFA3D0:01C5F19A] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Let us keep netconf truly transport independent as the choice of transport protocol can also be dictated by other reasons: - market acceptance - available toolkits Balazs Juergen Schoenwaelder wrote: > On Wed, Nov 23, 2005 at 08:13:21PM +0100, Eliot Lear wrote: > >>Glenn, >> >>What I'm saying is that while it is true that SSH is the "mandatory to >>implement", you only need to have application-level ACKs in the >>notification component if THEY are mandatory to implement. Otherwise >>you can leave it to the BEEP mapping and be done with it. > > > Again, > > lets first decide which semantics we need and then talk about the > implementation. I personally have bad feelings if sematics associated > with a netconf protocol operation are determined by the underlying > transport. > > /js > -- 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 Nov 25 08:56:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efe3r-0005Tp-Qa for netconf-archive@megatron.ietf.org; Fri, 25 Nov 2005 08:56:23 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27471 for ; Fri, 25 Nov 2005 08:55:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Efdqe-0008Ox-Fl for netconf-data@psg.com; Fri, 25 Nov 2005 13:42:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Efdqd-0008Oj-Gp for netconf@ops.ietf.org; Fri, 25 Nov 2005 13:42:43 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jAPDgMHS011838; Fri, 25 Nov 2005 07:42:23 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 25 Nov 2005 14:41:42 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508A481CC@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Netconf (E-mail)" Cc: Mark Baker , iesg@ietf.org Subject: IETF Last Call comments on draft-ietf-netconf-soap-06.txt Date: Fri, 25 Nov 2005 14:42:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk NetConf WG, and specifically author(s) of the SOAP document, please review and comment. Bert -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org]On Behalf Of Mark Baker Sent: Wednesday, November 23, 2005 21:37 To: iesg@ietf.org Subject: NETCONF over SOAP and BCP 56 I'd like to take issue with a claim made in the NETCONF over SOAP draft; http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-06.txt In section 2.4 regarding BCP 56, the draft says; "Fundamentally, these concerns lie directly with SOAP over HTTP, rather than the application of SOAP over HTTP to NETCONF." That is incorrect. The advice of BCP 56 is relevant to any use of HTTP. For example, BCP 56 provides guidance about the use of port numbers, security, and URI schemes, none of which SOAP (1.1 or 1.2) take any position on. Moreover, the SOAP specifications don't require that HTTP be used as a tunnel; they fully support the use of SOAP as an extension to the HTTP processing model. IMHO, either the draft needs to defend its disregard of many of the recommendations of BCP 56, or it needs to accomodate them as best it can. I expect this will be particularly difficult given that NETCONF is itself an application protocol, but at the very least I think the draft should recommend or require that port 80 not be used, or that a new HTTP method be used (viz a viz BCP 56 section 6), so as to separate NETCONF traffic from Web traffic. Thanks, P.S. http://xml.coverpages.org/draft-presuhn-nmwebdav-01.txt describes (at a very high level) a network configuration protocol that doesn't tunnel over HTTP, but instead uses HTTP/WebDAV as an application protocol. The use of SOAP is not described though, but you could imagine all of the configuration documents wrapped in a SOAP envelope. Such a use of HTTP for network configuration would probably comply with BCP 56. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com -- 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 Nov 25 11:53:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfgpW-00083n-2U for netconf-archive@megatron.ietf.org; Fri, 25 Nov 2005 11:53:46 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17454 for ; Fri, 25 Nov 2005 11:53:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Efgj4-000Pmg-IP for netconf-data@psg.com; Fri, 25 Nov 2005 16:47:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [64.40.101.249] (helo=www.icesoft.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Efgj1-000PmS-Ow for netconf@ops.ietf.org; Fri, 25 Nov 2005 16:47:03 +0000 Received: from [10.18.39.60] ([64.141.118.170]) by www.icesoft.com (Kerio MailServer 6.1.0) (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits)); Fri, 25 Nov 2005 08:47:11 -0800 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15508A481CC@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15508A481CC@nl0006exch001u.nl.lucent.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <615F6827-8F69-484A-A314-76B204AFA2B5@icesoft.com> Cc: Mark Baker , iesg@ietf.org Content-Transfer-Encoding: 7bit From: Ted Goddard Subject: Re: IETF Last Call comments on draft-ietf-netconf-soap-06.txt Date: Fri, 25 Nov 2005 09:46:37 -0700 To: "Netconf (E-mail)" , "Wijnen, Bert (Bert)" X-Mailer: Apple Mail (2.734) Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Please find my comments in line: On 25-Nov-05, at 6:42 AM, Wijnen, Bert (Bert) wrote: > NetConf WG, and specifically author(s) of the SOAP document, > > please review and comment. > > Bert > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org]On Behalf > Of Mark Baker > Sent: Wednesday, November 23, 2005 21:37 > To: iesg@ietf.org > Subject: NETCONF over SOAP and BCP 56 > > > I'd like to take issue with a claim made in the NETCONF over SOAP > draft; > > http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-06.txt > > In section 2.4 regarding BCP 56, the draft says; > > "Fundamentally, these concerns lie directly with SOAP over HTTP, > rather than the application of SOAP over HTTP to NETCONF." > > That is incorrect. The advice of BCP 56 is relevant to any use of > HTTP. I agree that BCP 56 is relevant to any use of HTTP; however BCP 56 makes recommendations that are at odds with the widespread practice of using HTTP as a universal tunneling protocol (however dangerous it may be, it is widespread, and it is even the expectation of many users of SOAP). Would the following wording be preferred? Fundamentally, many of these concerns lie directly with common usage of SOAP over HTTP, rather than the application of SOAP over HTTP to NETCONF. > For example, BCP 56 provides guidance about the use of port > numbers, security, and URI schemes, none of which SOAP (1.1 or 1.2) > take any position on. Moreover, the SOAP specifications don't > require that HTTP be used as a tunnel; they fully support the use > of SOAP as an extension to the HTTP processing model. > IMHO, either the draft needs to defend its disregard of many of the > recommendations of BCP 56, or it needs to accomodate them as best > it can. I expect this will be particularly difficult given that > NETCONF is itself an application protocol, but at the very least I > think the draft should recommend or require that port 80 not be > used, or that a new HTTP method be used (viz a viz BCP 56 section > 6), so as to separate NETCONF traffic from Web traffic. Requiring a new HTTP method would make NETCONF incompatible with existing SOAP implementations, but there is no difficulty with requiring a specific port. The draft currently contains the following text: It is also possible to respond to the concern on the re-use of port 80. A NETCONF SOAP service SHOULD be offered over a new standard port for NETCONF over SOAP (over HTTP) to be defined as requested in the IANA considerations of this document. and in the IANA Considerations section: The IANA is requested to assign TCP ports for NETCONF for SOAP over HTTP and SOAP over BEEP. Would it be preferred to revise the first paragraph to contain the following? The NETCONF SOAP service MUST be offered over the new standard port for NETCONF over SOAP Thanks, Ted. > Thanks, > > P.S. http://xml.coverpages.org/draft-presuhn-nmwebdav-01.txt > describes (at a very high level) a network configuration protocol > that doesn't tunnel over HTTP, but instead uses HTTP/WebDAV as an > application protocol. The use of SOAP is not described though, but > you could imagine all of the configuration documents wrapped in a > SOAP envelope. Such a use of HTTP for network configuration would > probably comply with BCP 56. > > Mark. > -- > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca > Coactus; Web-inspired integration strategies http://www.coactus.com > > -- > 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 Nov 25 12:23:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfhHu-0007M9-HP for netconf-archive@megatron.ietf.org; Fri, 25 Nov 2005 12:23:06 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21077 for ; Fri, 25 Nov 2005 12:22:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfhAt-0002l7-KW for netconf-data@psg.com; Fri, 25 Nov 2005 17:15:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.65.151.107] (helo=sharplabs.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfhAq-0002ku-VD for netconf@ops.ietf.org; Fri, 25 Nov 2005 17:15:49 +0000 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id jAPHFRfq012057; Fri, 25 Nov 2005 09:15:27 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Fri, 25 Nov 2005 09:17:45 -0800 Message-ID: From: "McDonald, Ira" To: "'Ted Goddard'" , "Netconf (E-mail)" , "Wijnen, Bert (Bert)" Cc: Mark Baker , iesg@ietf.org Subject: RE: IETF Last Call comments on draft-ietf-netconf-soap-06.txt Date: Fri, 25 Nov 2005 09:17:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, I'd suggest revising Ted's text to be considerably firmer, e.g., The NETCONF SOAP service MUST always be supported over the new standard port for NETCONF over SOAP and all conforming implementations MUST default to attempting connections over this new standard port for NETCONF Leaving "wiggle room" for implementations to allow administrators to force immediate use of port 80 (as first choice) is unwise and certainly in conflict with BCP 56. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Ted Goddard > Sent: Friday, November 25, 2005 11:47 AM > To: Netconf (E-mail); Wijnen, Bert (Bert) > Cc: Mark Baker; iesg@ietf.org > Subject: Re: IETF Last Call comments on draft-ietf-netconf-soap-06.txt > > > > Please find my comments in line: > > On 25-Nov-05, at 6:42 AM, Wijnen, Bert (Bert) wrote: > > > NetConf WG, and specifically author(s) of the SOAP document, > > > > please review and comment. > > > > Bert > > -----Original Message----- > > From: iesg-bounces@ietf.org > [mailto:iesg-bounces@ietf.org]On Behalf > > Of Mark Baker > > Sent: Wednesday, November 23, 2005 21:37 > > To: iesg@ietf.org > > Subject: NETCONF over SOAP and BCP 56 > > > > > > I'd like to take issue with a claim made in the NETCONF over SOAP > > draft; > > > > http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-06.txt > > > > In section 2.4 regarding BCP 56, the draft says; > > > > "Fundamentally, these concerns lie directly with SOAP over HTTP, > > rather than the application of SOAP over HTTP to NETCONF." > > > > That is incorrect. The advice of BCP 56 is relevant to any use of > > HTTP. > > I agree that BCP 56 is relevant to any use of HTTP; however > BCP 56 makes recommendations that are at odds with the widespread > practice of using HTTP as a universal tunneling protocol (however > dangerous it may be, it is widespread, and it is even the > expectation of many users of SOAP). Would the following wording be > preferred? > > Fundamentally, many of these concerns lie directly with > common usage of SOAP over HTTP, rather than the application > of SOAP over HTTP to NETCONF. > > > For example, BCP 56 provides guidance about the use of port > > numbers, security, and URI schemes, none of which SOAP (1.1 > or 1.2) > > take any position on. Moreover, the SOAP specifications don't > > require that HTTP be used as a tunnel; they fully support the use > > of SOAP as an extension to the HTTP processing model. > > > IMHO, either the draft needs to defend its disregard of > many of the > > recommendations of BCP 56, or it needs to accomodate them as best > > it can. I expect this will be particularly difficult given that > > NETCONF is itself an application protocol, but at the very least I > > think the draft should recommend or require that port 80 not be > > used, or that a new HTTP method be used (viz a viz BCP 56 section > > 6), so as to separate NETCONF traffic from Web traffic. > > Requiring a new HTTP method would make NETCONF incompatible with > existing SOAP implementations, but there is no difficulty with > requiring a specific port. The draft currently contains the > following text: > > It is also possible to respond to the concern on the > re-use of port 80. A NETCONF SOAP service SHOULD be offered > over a new standard port for NETCONF over SOAP (over HTTP) > to be defined as requested in the IANA considerations of > this document. > > and in the IANA Considerations section: > > The IANA is requested to assign TCP ports for NETCONF for > SOAP over HTTP and SOAP over BEEP. > > Would it be preferred to revise the first paragraph to contain > the following? > > The NETCONF SOAP service MUST be offered > over the new standard port for NETCONF over SOAP > > Thanks, > Ted. > > > > Thanks, > > > > P.S. http://xml.coverpages.org/draft-presuhn-nmwebdav-01.txt > > describes (at a very high level) a network configuration protocol > > that doesn't tunnel over HTTP, but instead uses HTTP/WebDAV as an > > application protocol. The use of SOAP is not described > though, but > > you could imagine all of the configuration documents wrapped in a > > SOAP envelope. Such a use of HTTP for network configuration would > > probably comply with BCP 56. > > > > Mark. > > -- > > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca > Coactus; Web-inspired integration strategies http://www.coactus.com > > -- > 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 Nov 25 12:37:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfhWA-0001b3-J4 for netconf-archive@megatron.ietf.org; Fri, 25 Nov 2005 12:37:50 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22873 for ; Fri, 25 Nov 2005 12:37:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfhKM-0003nS-0X for netconf-data@psg.com; Fri, 25 Nov 2005 17:25:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1EfhKJ-0003mv-7D for netconf@ops.ietf.org; Fri, 25 Nov 2005 17:25:35 +0000 Received: (qmail 1766 invoked by uid 78); 25 Nov 2005 17:25:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.67 with SMTP; 25 Nov 2005 17:25:35 -0000 Message-ID: <4387491E.1050006@andybierman.com> Date: Fri, 25 Nov 2005 09:25:50 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Balazs Lengyel CC: netconf@ops.ietf.org Subject: Re: Size matters was Re: notification charter proposal References: <6E21698722408147BEA594E073E2B0AB0105B6A7@xmb-sjc-223.amer.cisco.com> <4386C9C2.2070005@ericsson.com> In-Reply-To: <4386C9C2.2070005@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Balazs Lengyel wrote: > Please dont set a max message size generally for netconf !!! We are discussing the notion of setting a minimum value that conforming implementations can use. We aren't setting any maximum value, although I suggested 4 billion bytes so my code can store your max-message-size in a 4 byte number instead of an 8-byte (long long) number. If anybody out there is planning an implementation with a message size bigger than 4 billion bytes, please let me know :-) > > For me one attractive usage of netconf would be to retrieve the > complete configuration of a node. If we set a mandatory max-size for > all netconf messages (as opposed to setting it for notifications > only) this usage would become impossible. For big nodes it is anyone's > guess what the size of a full configuration can be. We have nodes that > contain the data of 10 million subscribers. You don't HAVE to design an application to get 10 million config entries at once, but if even this will fit in a 4 billion byte message. Andy > > Balazs Lengyel Ericsson Hungary Ltd. > > Hector Trevino (htrevino) wrote: > >> >> I agree that this is part of the protocol definition but I see it as >> outside the scope of the charter definition. I'd assume none of this >> will be included in the charter. >> >> >> I don't think the spec should set a hard limit on the max message size. >> I agree w/Juergen about not limiting the protocol but rather allowing >> implementations to advertise their max message sizes (if one is set). It >> may be better to say something like app layer message segmentation is >> not allowed. But recommendations/guidelines for max message sizes should >> be provided in the spec. >> Hector >> >> >> >> -----Original Message----- >> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >> Behalf Of Andy Bierman >> Sent: Tuesday, November 22, 2005 4:01 PM >> To: Tom Petch >> Cc: netconf@ops.ietf.org >> Subject: Re: Size matters was Re: notification charter proposal >> >> Tom Petch wrote: >> >> >>> >>> Tom Petch >>> ----- Original Message ----- >>> From: "Andy Bierman" >>> To: >>> Cc: "Tom Petch" ; >>> Sent: Tuesday, November 22, 2005 4:41 PM >>> Subject: Re: notification charter proposal > > >>> >>> >>> >>>> That would be fine with me. >>>> I brought up the issue because the problem is obviously worse for >>>> notifications than RPCs, because the lack of an application layer >>>> ACK (which effectively is). >>>> >>>> The reason for setting a minimum is to allow NMS developers to code to >>> >> >> >>>> some reasonable minimum. The market will help keep things somewhat >>>> reasonable, but we could see a range from 1500 to 64K as the minimum. >>> >> >> >>>> Is that OK? >>>> >>>> Andy >>>> >>>> >>> >>> >>> I raised size because there are references appearing on the list >>> calling for something syslog-like and size has been an issue with >>> syslog that has not been satisfactorily resolved. syslog unearthed two >> >> >> >>> contrasting viewpoints, one that messages should not exceed 2k or >>> even 1k, the other that 64k should be supported (for at least one >> >> >> application). >> >>> Netconf is more virgin territory than syslog is but I do believe is >>> setting a Maximum size, at least to start with; but I do not see >>> this as anything to do with the charter:-). >>> >>> >> >> >> This is part of protocol syntax and semantics. >> >> IMO, the best approach is to have the NC peer advertise its >> max-message-size. The number should be an PositiveInteger, so that >> would set a theoretical max-message-size of 4G-1 bytes. >> >> >> A separate issue is whether there is a minimum an NC peer can set this >> parameter to, somewhat higher than zero. I don't see any consensus yet >> on how much higher to set the minimum. >> >> >> Another important issue: Can an NC peer (optionally?) send its >> max-message-size in the exchange? This doesn't mean the other >> NC peer has to do anything with the value, it just provides a good guess >> at the number instead of trying >> various message sizes to see what breaks. Advertising a >> max-message-size doesn't mean you won't get messages greater than that >> size. >> >> >>> Tom Petch >>> >>> >>> >>> >> >> >> 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: > > > -- > 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 Nov 25 12:41:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfhZQ-0002F1-KA for netconf-archive@megatron.ietf.org; Fri, 25 Nov 2005 12:41:12 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23547 for ; Fri, 25 Nov 2005 12:40:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfhQS-0004Qn-Fa for netconf-data@psg.com; Fri, 25 Nov 2005 17:31:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1EfhQR-0004Qa-Qy for netconf@ops.ietf.org; Fri, 25 Nov 2005 17:31:55 +0000 Received: (qmail 4939 invoked by uid 78); 25 Nov 2005 17:31:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.51 with SMTP; 25 Nov 2005 17:31:55 -0000 Message-ID: <43874A9B.6000703@andybierman.com> Date: Fri, 25 Nov 2005 09:32:11 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eliot Lear CC: "McDonald, Ira" , netconf@ops.ietf.org Subject: Re: notification charter proposal References: <4386C82C.2010503@cisco.com> In-Reply-To: <4386C82C.2010503@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eliot Lear wrote: >McDonald, Ira wrote: > > >>Hi, >> >>As Juergen Schoenwaelder just pointed out - a transport layer >>ACK does NOT have the same semantics as an upper layer ACK >>that indicates receipt of a well-formed XML message. >> >> > >What is of particular concern is the way things are going in ISMS, where >because of the existing ASIs and elements of procedure a question came >up over how to signal back to the upper layers when a TCP connection has >failed. One solution was to simply ignore the problem and let the upper >layer deal with the problem as if the transport WERE unreliable. I >don't like that approach because it doesn't properly take advantage of >TCP's ability to alert the application to a network problem. > >Related- we are currently in a bit of a scrum with ATIS TMOC over IPFIX >about application layer acknowledgments. There they want 100% >reliability "from disk to disk". That means that even a TCP ACK is not >sufficient because the recipient stack will have ACKed probably several >ms before that point. > >Here is the question: what level of reliability is necessary for the >applications we have in mind? The above example is for accounting where >arguably money is involved. Are these notifications going to be used to >derive a revenue event (SLA management, for instance) such that if a >recipient crashes and the event is lost after having been acknowledged >somebody would be upset? > >I don't envision that. Therefore I wouldn't include it. However, if >somebody wants it they can still have it by using BEEP. All of this >having been said... > > > >>Confusing the two is not helpful - NetConf is supposed to >>behave the same over any transport. >> >> > >If NETCONF is to behave the same over any transport then why have more >than one? Why are we going through a last call for THREE transports? > > This is irrelevant. The operation does not behave differently over the 3 transports. All options to all operations are available, regardless of transport choice. Make the same true for notifications or (IMO) this whole thing is dead on arrival. >Eliot > > 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 Nov 25 13:45:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfiZK-0000NW-7R for netconf-archive@megatron.ietf.org; Fri, 25 Nov 2005 13:45:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01617 for ; Fri, 25 Nov 2005 13:44:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfiMG-000AaM-Ff for netconf-data@psg.com; Fri, 25 Nov 2005 18:31:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1EfiMD-000Aa6-VB for netconf@ops.ietf.org; Fri, 25 Nov 2005 18:31:38 +0000 Received: (qmail 19729 invoked by uid 78); 25 Nov 2005 18:31:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.67 with SMTP; 25 Nov 2005 18:31:37 -0000 Message-ID: <438758A3.6050603@andybierman.com> Date: Fri, 25 Nov 2005 10:32:03 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: NETCONF Notifications: Consensus Points Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I'd like to try to gauge WG consensus on some recent mailing list issues. Please object if you think I've totally got it wrong: Terminology: The term Notification is preferred over Event Message. Max Message Size: A NETCONF peer should advertise its max message. The standard should not set a max-size although it is understood that implementations can use a max message size. There seems to be some consensus for mandating a minimum value for this parameter, although it's not clear what the exact should be (something between 1500 and 65535 bytes). Application-Level ACKs It is not clear what a sender would do differently even if it knew the receiver did not understand the message. Without specific features in the protocol which would need app-level ACKs (such as data model version negotiation), the cost and complexity of this feature cannot be justified. Transport-Level ACKs There is WG consensus that this feature is required. Feature Consistency at the Protocol Layer There is WG consensus that the protocol-level notification features must be consistent across the supported transports. However, there is not yet WG consensus that NETCONF over SOAP must be supported. The discussions have focused on SSH and BEEP. Each time it is mentioned that SOAP/HTTP cannot support this feature, the issue is ignored. Notification Info Model/Payload There is WG consensus to reuse syslog classification, although the ability to transfer additional user data (similar to the OBJECTS clause in an SNMP notification) is also required. The option of asking the SYSLOG WG for enhancements to RFC 3195 is also possible, and some WG members prefer this approach if syslog is going to be enhanced in any meaningful way. Events Draft as Starting Point There is WG consensus to use draft-chisholm-netconf-event-01.txt as the starting point for this work, even though there are strong objections to specific details in the draft. It is understood that the WG is addressing the feature list in the WG charter, not in this draft, if the two are in conflict. -- 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 Nov 25 15:56:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfkcZ-0006Vs-0O for netconf-archive@megatron.ietf.org; Fri, 25 Nov 2005 15:56:39 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15971 for ; Fri, 25 Nov 2005 15:55:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfkUK-000Ow0-3a for netconf-data@psg.com; Fri, 25 Nov 2005 20:48:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfkUJ-000Ovo-3E for netconf@ops.ietf.org; Fri, 25 Nov 2005 20:48:07 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jAPKm2N23935; Fri, 25 Nov 2005 15:48:02 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Notifications: Consensus Points Date: Fri, 25 Nov 2005 15:46:53 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D074BB495@zcarhxm0.corp.nortel.com> Thread-Topic: NETCONF Notifications: Consensus Points Thread-Index: AcXx8Ik/p32QC2p4QmS6dY1fCliRfwAD2q3Q From: "Glenn Waters" To: "Andy Bierman" , Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Inline. > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Andy Bierman > Sent: Friday, November 25, 2005 13:32 > To: netconf@ops.ietf.org > Subject: NETCONF Notifications: Consensus Points >=20 > Hi, >=20 > I'd like to try to gauge WG consensus on some recent > mailing list issues. Please object if you think I've > totally got it wrong: >=20 > Terminology: >=20 > The term Notification is preferred over Event Message. I'm OK with this. > Max Message Size: >=20 > A NETCONF peer should advertise its max message. > The standard should not set a max-size although it is > understood that implementations can use a max message size. > There seems to be some consensus for mandating a minimum > value for this parameter, although it's not clear what the exact > should be (something between 1500 and 65535 bytes). This sounds like something that should be in the Netconf base protocol. Notifications are not special. I propose that we do nothing here. > Application-Level ACKs >=20 > It is not clear what a sender would do differently even > if it knew the receiver did not understand the message. > Without specific features in the protocol which would > need app-level ACKs (such as data model version negotiation), > the cost and complexity of this feature cannot be justified. I think that we require Netconf Notification ACKs, and they can be optional as was done in SNMPv3 (i.e.: unACKed traps, ACKed informs). They are required for cases where the sender needs to know if the information was successful transmitted and may decide to retransmit at a later time. =20 > Transport-Level ACKs >=20 > There is WG consensus that this feature is required. Is there such a thing as a transport level ACK for SSH? Elliot has made it clear that there is a transport level ACK for BEEP. =20 > Feature Consistency at the Protocol Layer >=20 > There is WG consensus that the protocol-level notification > features must be consistent across the supported transports. > However, there is not yet WG consensus that NETCONF over SOAP > must be supported. The discussions have focused on SSH and BEEP. > Each time it is mentioned that SOAP/HTTP cannot support this > feature, the issue is ignored. I agree that notification features are must be consistent regardless of transport. I'm not sure what you are proposing for SOAP. Sounds like you are proposing that we kill that transport. Please clarify. > Notification Info Model/Payload >=20 > There is WG consensus to reuse syslog classification, although > the ability to transfer additional user data (similar to the OBJECTS > clause in an SNMP notification) is also required. The option > of asking the SYSLOG WG for enhancements to RFC 3195 is also > possible, and some WG members prefer this approach if syslog > is going to be enhanced in any meaningful way. I don't have an opinion on this yet, however, this does feel like we will constrain ourselves too much. =20 > Events Draft as Starting Point >=20 > There is WG consensus to use draft-chisholm-netconf-event-01.txt as > the starting point for this work, even though there are strong > objections to specific details in the draft. It is understood > that the WG is addressing the feature list in the WG charter, > not in this draft, if the two are in conflict. I agree. Regards, /gww=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 Nov 25 16:30:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efl9I-0002Ro-P9 for netconf-archive@megatron.ietf.org; Fri, 25 Nov 2005 16:30:30 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19658 for ; Fri, 25 Nov 2005 16:29:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Efl4T-00034n-Ui for netconf-data@psg.com; Fri, 25 Nov 2005 21:25:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1Efl4S-00034c-Vi for netconf@ops.ietf.org; Fri, 25 Nov 2005 21:25:29 +0000 Received: (qmail 15433 invoked by uid 78); 25 Nov 2005 21:25:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.56 with SMTP; 25 Nov 2005 21:25:28 -0000 Message-ID: <4387817C.70209@andybierman.com> Date: Fri, 25 Nov 2005 13:26:20 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Glenn Waters CC: netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points References: <085091CB2CA14E4B8B163FFC37C84E9D074BB495@zcarhxm0.corp.nortel.com> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D074BB495@zcarhxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Glenn Waters wrote: >Inline. > > > >>-----Original Message----- >>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] >> >> >On > > >>Behalf Of Andy Bierman >>Sent: Friday, November 25, 2005 13:32 >>To: netconf@ops.ietf.org >>Subject: NETCONF Notifications: Consensus Points >> >>Hi, >> >>I'd like to try to gauge WG consensus on some recent >>mailing list issues. Please object if you think I've >>totally got it wrong: >> >>Terminology: >> >> The term Notification is preferred over Event Message. >> >> > >I'm OK with this. > > > >>Max Message Size: >> >> A NETCONF peer should advertise its max message. >> The standard should not set a max-size although it is >> understood that implementations can use a max message size. >> There seems to be some consensus for mandating a minimum >> value for this parameter, although it's not clear what the exact >> should be (something between 1500 and 65535 bytes). >> >> > >This sounds like something that should be in the Netconf base protocol. >Notifications are not special. I propose that we do nothing here. > > I don't understand this logic. How does doing nothing address the problem? IMO, it should be addressed, regardless of the document that contains the text. I saw a lot of email agreeing that advertising the max-message-size needs to be added. > > >>Application-Level ACKs >> >> It is not clear what a sender would do differently even >> if it knew the receiver did not understand the message. >> Without specific features in the protocol which would >> need app-level ACKs (such as data model version negotiation), >> the cost and complexity of this feature cannot be justified. >> >> > >I think that we require Netconf Notification ACKs, and they can be >optional as was done in SNMPv3 (i.e.: unACKed traps, ACKed informs). >They are required for cases where the sender needs to know if the >information was successful transmitted and may decide to retransmit at a >later time. > > I'm not sure we are all clear on the semantics here. What I think we mean by application-layer ACK is the receiver understood the message. TCP lets us know the receiver got the message. I don't see how retransmitting at a later time will help the receiver understand the message (delivered as sent) any better, unless the reason the message was garbled is an intermittent bug in the sender. I don't think we need to worry about this case in the protocol. Because if this isn't the case, then the exact same error condition will occur no matter how many times the sender retries. > > > >>Transport-Level ACKs >> >> There is WG consensus that this feature is required. >> >> > >Is there such a thing as a transport level ACK for SSH? Elliot has made >it clear that there is a transport level ACK for BEEP. > > I'm thinking of TCP here. I understand this will not catch buggy implementations sending malformed XML. I don't agree that the protocol should be designed to accommodate buggy implementations. > > > >>Feature Consistency at the Protocol Layer >> >> There is WG consensus that the protocol-level notification >> features must be consistent across the supported transports. >> However, there is not yet WG consensus that NETCONF over SOAP >> must be supported. The discussions have focused on SSH and BEEP. >> Each time it is mentioned that SOAP/HTTP cannot support this >> feature, the issue is ignored. >> >> > >I agree that notification features are must be consistent regardless of >transport. > >I'm not sure what you are proposing for SOAP. Sounds like you are >proposing that we kill that transport. Please clarify. > > If nobody is implementing it, then we can't let its limitations impact this work. I've heard one vendor tell me they would probably implement it if some customer really wanted it, but I haven't heard of any products using the SOAP/HTTP or SOAP/BEEP transports. If you are out there, please speak up! > > >>Notification Info Model/Payload >> >> There is WG consensus to reuse syslog classification, although >> the ability to transfer additional user data (similar to the OBJECTS >> clause in an SNMP notification) is also required. The option >> of asking the SYSLOG WG for enhancements to RFC 3195 is also >> possible, and some WG members prefer this approach if syslog >> is going to be enhanced in any meaningful way. >> >> > >I don't have an opinion on this yet, however, this does feel like we >will constrain ourselves too much. > > Well, I have a different take on constraints -- like "real-world proven operational requirement". Experiments should be done in the IRTF. We should standardize stuff that has been shown to work. > > > >>Events Draft as Starting Point >> >> There is WG consensus to use draft-chisholm-netconf-event-01.txt as >> the starting point for this work, even though there are strong >> objections to specific details in the draft. It is understood >> that the WG is addressing the feature list in the WG charter, >> not in this draft, if the two are in conflict. >> >> > >I agree. > >Regards, /gww > > > > 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 Nov 25 17:32:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efm73-0005Ps-1k for netconf-archive@megatron.ietf.org; Fri, 25 Nov 2005 17:32:13 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25806 for ; Fri, 25 Nov 2005 17:31:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Efm0K-0009FY-3d for netconf-data@psg.com; Fri, 25 Nov 2005 22:25:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [64.40.101.249] (helo=www.icesoft.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Efm0J-0009FH-FC for netconf@ops.ietf.org; Fri, 25 Nov 2005 22:25:15 +0000 Received: from [10.18.39.60] ([64.141.118.170]) by www.icesoft.com (Kerio MailServer 6.1.0) (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits)); Fri, 25 Nov 2005 13:55:42 -0800 Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <438758A3.6050603@andybierman.com> References: <438758A3.6050603@andybierman.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Goddard Subject: Re: NETCONF Notifications: Consensus Points Date: Fri, 25 Nov 2005 14:55:09 -0700 To: Andy Bierman , "Netconf (E-mail)" X-Mailer: Apple Mail (2.734) Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 25-Nov-05, at 11:32 AM, Andy Bierman wrote: > Feature Consistency at the Protocol Layer > > There is WG consensus that the protocol-level notification > features must be consistent across the supported transports. > However, there is not yet WG consensus that NETCONF over SOAP > must be supported. The discussions have focused on SSH and BEEP. > Each time it is mentioned that SOAP/HTTP cannot support this > feature, the issue is ignored. Notifications for NETCONF over SOAP/HTTP could be implemented using: 1. Separate HTTP connections for NETCONF management and NETCONF notifications channels 2. HTTP response to a notification request delayed until notifications are available Ted. -- 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 Nov 26 22:04:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgCpx-0003EB-CT for netconf-archive@megatron.ietf.org; Sat, 26 Nov 2005 22:04:21 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20093 for ; Sat, 26 Nov 2005 22:03:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgCct-000GVf-2Y for netconf-data@psg.com; Sun, 27 Nov 2005 02:50:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [207.69.200.28] (helo=pop04.mail.atl.earthlink.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgCcq-000GVO-6N for netconf@ops.ietf.org; Sun, 27 Nov 2005 02:50:50 +0000 Received: from mswamui-bichon.atl.sa.earthlink.net ([209.86.224.26]) by pop04.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1EgCco-0003US-00 for netconf@ops.ietf.org; Sat, 26 Nov 2005 21:50:46 -0500 Message-ID: <18853747.1133059846319.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Date: Sat, 26 Nov 2005 18:50:45 -0800 (GMT-08:00) From: Randy Presuhn Reply-To: Randy Presuhn To: netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi - > From: Andy Bierman > Sent: Nov 25, 2005 10:32 AM > To: netconf@ops.ietf.org > Subject: NETCONF Notifications: Consensus Points ... > Terminology: > > The term Notification is preferred over Event Message. My understanding of current IETF usage of "Notification" is as a way of talking about the realization of a NOTIFICATION-TYPE, without pinning it down to the specific SNMP PDU=type used to carry the information. I think that using it in the context of netconf to refer to a particular message type would only be asking for confusion. ... > Application-Level ACKs > > It is not clear what a sender would do differently even > if it knew the receiver did not understand the message. This is only one of the possible reasons for application-level acknowledgments. A more important one is that for purposes such as log maintenance, it is essential that the generation of the acknowledgment be under the application's control, rather than, for example, the TCP stack's. Otherwise, race conditions arise in which the notification sender will erroneously believe the information has been processed (e.g., written to disk) by the receiver. > Without specific features in the protocol which would > need app-level ACKs (such as data model version negotiation), > the cost and complexity of this feature cannot be justified. ... This is based on the premise that the sole reason for application level acknowledgment is confirmation that it could "understand" the data. For logging applications, this is neither necessary nor sufficient. Randy -- 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 Nov 27 00:48:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgFOx-0002TZ-8N for netconf-archive@megatron.ietf.org; Sun, 27 Nov 2005 00:48:39 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01320 for ; Sun, 27 Nov 2005 00:47:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgFIz-0000TV-Uo for netconf-data@psg.com; Sun, 27 Nov 2005 05:42:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgFIz-0000TK-55 for netconf@ops.ietf.org; Sun, 27 Nov 2005 05:42:29 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 26 Nov 2005 21:42:29 -0800 X-IronPort-AV: i="3.97,380,1125903600"; d="scan'208"; a="234600626:sNHT26747204" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jAR5gQ6a020109; Sat, 26 Nov 2005 21:42:26 -0800 (PST) Received: from xmb-sjc-212.amer.cisco.com ([171.70.151.141]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 26 Nov 2005 21:42:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Notifications: Consensus Points Date: Sat, 26 Nov 2005 21:42:24 -0800 Message-ID: Thread-Topic: NETCONF Notifications: Consensus Points Thread-Index: AcXy/em/8e40V5+GQu6Xxw6JzNu6YwAFycnw From: "Andrea Westerinen \(andreaw\)" To: "Randy Presuhn" , X-OriginalArrivalTime: 27 Nov 2005 05:42:26.0361 (UTC) FILETIME=[5909E290:01C5F315] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable One usage of application-level ACKs (by the sender) is to disable sending notifications/event messages until specifically re-enabled. =20 Andrea > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Randy Presuhn > Sent: Saturday, November 26, 2005 6:51 PM > To: netconf@ops.ietf.org > Subject: Re: NETCONF Notifications: Consensus Points >=20 > Hi - >=20 > > From: Andy Bierman > > Sent: Nov 25, 2005 10:32 AM > > To: netconf@ops.ietf.org > > Subject: NETCONF Notifications: Consensus Points > ... > > Terminology: > > > > The term Notification is preferred over Event Message. >=20 > My understanding of current IETF usage of "Notification" is=20 > as a way of talking about the realization of a=20 > NOTIFICATION-TYPE, without pinning it down to the specific=20 > SNMP PDU=3Dtype used to carry the information. I think that=20 > using it in the context of netconf to refer to a particular=20 > message type would only be asking for confusion. >=20 > ... > > Application-Level ACKs > > > > It is not clear what a sender would do differently even > > if it knew the receiver did not understand the message. >=20 > This is only one of the possible reasons for=20 > application-level acknowledgments. A more important one is=20 > that for purposes such as log maintenance, it is essential=20 > that the generation of the acknowledgment be under the=20 > application's control, rather than, for example, the TCP=20 > stack's. Otherwise, race conditions arise in which the=20 > notification sender will erroneously believe the information=20 > has been processed (e.g., written to disk) by the receiver. >=20 > > Without specific features in the protocol which would =20 > need app-level=20 > > ACKs (such as data model version negotiation), the cost and=20 > > complexity of this feature cannot be justified. > ... >=20 > This is based on the premise that the sole reason for=20 > application level acknowledgment is confirmation that it=20 > could "understand" > the data. For logging applications, this is neither=20 > necessary nor sufficient. >=20 > Randy >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org=20 > 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: From owner-netconf@ops.ietf.org Sun Nov 27 01:23:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgFwj-0001Qa-Km for netconf-archive@megatron.ietf.org; Sun, 27 Nov 2005 01:23:33 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03948 for ; Sun, 27 Nov 2005 01:22:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgFro-0002VU-4L for netconf-data@psg.com; Sun, 27 Nov 2005 06:18:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.54 (FreeBSD)) id 1EgFrn-0002VH-IR for netconf@ops.ietf.org; Sun, 27 Nov 2005 06:18:27 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id jAR6I8059513; Sat, 26 Nov 2005 22:18:12 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jAR6Hw513366; Sat, 26 Nov 2005 22:17:58 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id jAR6N8YE007537; Sun, 27 Nov 2005 01:23:12 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200511270623.jAR6N8YE007537@idle.juniper.net> To: Andy Bierman cc: Balazs Lengyel , netconf@ops.ietf.org Subject: Re: Size matters was Re: notification charter proposal In-Reply-To: Your message of "Fri, 25 Nov 2005 09:25:50 PST." <4387491E.1050006@andybierman.com> Date: Sun, 27 Nov 2005 01:23:08 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Andy Bierman writes: >Balazs Lengyel wrote: >> Please dont set a max message size generally for netconf !!! >We are discussing the notion of setting a minimum value >that conforming implementations can use. Setting a minimum maximum effectively sets the maximum an implementation can count on the other side implementing, which quickly turns into a hard restriction. Instead we should have any message size restrictions be passed in to the server at subscription time. If the client gives a number larger than the server can send, it's ignored. If the number is smaller, then the server must truncate. If the number is not provided, the server is freed from worrying about the client's message size considerations. >If anybody out there is planning an implementation with >a message size bigger than 4 billion bytes, please let me know :-) You are _so_ 32-bit, man ;^) Thanks, Phil -- 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 Nov 27 01:24:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgFxB-0001W4-Qr for netconf-archive@megatron.ietf.org; Sun, 27 Nov 2005 01:24:04 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03972 for ; Sun, 27 Nov 2005 01:23:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgFpm-0002QP-8R for netconf-data@psg.com; Sun, 27 Nov 2005 06:16:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.69.195.63] (helo=pop-satin.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgFpj-0002QD-D7 for netconf@ops.ietf.org; Sun, 27 Nov 2005 06:16:21 +0000 Received: from h-68-165-7-59.snvacaid.dynamic.covad.net ([68.165.7.59] helo=oemcomputer) by pop-satin.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1EgFpi-0003Yl-00 for netconf@ops.ietf.org; Sun, 27 Nov 2005 01:16:18 -0500 Message-ID: <000401c5f31a$bba9e4e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: NETCONF Notifications: Consensus Points Date: Sat, 26 Nov 2005 22:20:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi - > From: "Andrea Westerinen (andreaw)" > To: "Randy Presuhn" ; > Sent: Saturday, November 26, 2005 9:42 PM > Subject: RE: NETCONF Notifications: Consensus Points > > One usage of application-level ACKs (by the sender) is to disable > sending notifications/event messages until specifically re-enabled. ... That depends on how one structures the protocol. My initial reaction to such a proposed usage is, in admittedly non-technical terms, "Eww, gross!" More to the point, if the protocol only permits a single notification "in the pipe" at a time, it would be unsuitable for use in high-delay (think NASA) environments. Perhaps we can live with that; I don't know whether anyone would use netconf in high-delay environments. This is not a necessary property of application-level acknowledgements; an example of a protocol that does not have this property is CMIP. Randy -- 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 Nov 27 10:20:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgOKF-0002kd-LD for netconf-archive@megatron.ietf.org; Sun, 27 Nov 2005 10:20:23 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25691 for ; Sun, 27 Nov 2005 10:19:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgOA1-0006rd-F2 for netconf-data@psg.com; Sun, 27 Nov 2005 15:09:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1EgO9s-0006qW-NU for netconf@ops.ietf.org; Sun, 27 Nov 2005 15:09:40 +0000 Received: (qmail 16733 invoked by uid 78); 27 Nov 2005 15:09:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.51 with SMTP; 27 Nov 2005 15:09:40 -0000 Message-ID: <4389CBB7.9080208@andybierman.com> Date: Sun, 27 Nov 2005 07:07:35 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phil Shafer CC: Balazs Lengyel , netconf@ops.ietf.org Subject: Re: Size matters was Re: notification charter proposal References: <200511270623.jAR6N8YE007537@idle.juniper.net> In-Reply-To: <200511270623.jAR6N8YE007537@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Phil Shafer wrote: >Andy Bierman writes: > > >>Balazs Lengyel wrote: >> >> >>>Please dont set a max message size generally for netconf !!! >>> >>> >>We are discussing the notion of setting a minimum value >>that conforming implementations can use. >> >> > >Setting a minimum maximum effectively sets the maximum an implementation >can count on the other side implementing, which quickly turns into >a hard restriction. > > This is possible, but IMO NMS developers from a company will pressure the agent developers in that company to provide them with a reasonable max-size. You set the bar at 64K, and it's not such a bad restriction. I don't think we should try to set a limit, especially if it is a really low number like 1500. I stated in the previous mail that there isn't consensus to set a limit, so I think this topic can be closed now. >Instead we should have any message size restrictions be passed in >to the server at subscription time. If the client gives a number >larger than the server can send, it's ignored. If the number is >smaller, then the server must truncate. If the number is not >provided, the server is freed from worrying about the client's >message size considerations. > > Well put. > > >>If anybody out there is planning an implementation with >>a message size bigger than 4 billion bytes, please let me know :-) >> >> > >You are _so_ 32-bit, man ;^) > > Hey! I switched over from ASM to C in '86, but I still hate to waste memory or CPU cycles. ;-) >Thanks, > Phil > > 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 Nov 27 10:38:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgObg-0006ka-1a for netconf-archive@megatron.ietf.org; Sun, 27 Nov 2005 10:38:24 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27677 for ; Sun, 27 Nov 2005 10:37:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgOWZ-0008Lu-HC for netconf-data@psg.com; Sun, 27 Nov 2005 15:33:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1EgOWY-0008Lj-QW for netconf@ops.ietf.org; Sun, 27 Nov 2005 15:33:06 +0000 Received: (qmail 28383 invoked by uid 78); 27 Nov 2005 15:33:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.59 with SMTP; 27 Nov 2005 15:33:06 -0000 Message-ID: <4389D1B1.8020207@andybierman.com> Date: Sun, 27 Nov 2005 07:33:05 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn CC: netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points References: <18853747.1133059846319.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> In-Reply-To: <18853747.1133059846319.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Presuhn wrote: >Hi - > > > >>From: Andy Bierman >>Sent: Nov 25, 2005 10:32 AM >>To: netconf@ops.ietf.org >>Subject: NETCONF Notifications: Consensus Points >> >> >... > > >>Terminology: >> >> The term Notification is preferred over Event Message. >> >> > >My understanding of current IETF usage of "Notification" is as a >way of talking about the realization of a NOTIFICATION-TYPE, without >pinning it down to the specific SNMP PDU=type used to carry the >information. I think that using it in the context of netconf to refer >to a particular message type would only be asking for confusion. > > I understand the term "SNMP Notification" to mean that, but not the generic term. Many protocols have notifications. Only SNMP experts associate the generic term exclusively with SNMP. ;-) We have used the term 'NETCONF Notification' since the first XMLCONF draft. I really don't see the WG consensus to change it now. >... > > >>Application-Level ACKs >> >> It is not clear what a sender would do differently even >> if it knew the receiver did not understand the message. >> >> > >This is only one of the possible reasons for application-level >acknowledgments. A more important one is that for purposes >such as log maintenance, it is essential that the generation >of the acknowledgment be under the application's control, rather >than, for example, the TCP stack's. Otherwise, race conditions >arise in which the notification sender will erroneously believe >the information has been processed (e.g., written to disk) by the >receiver. > > I'm not sure what this has to do with NETCONF. If the sender cares about the difference in timing between the receiver timestamping in the TCP stack vs. the application, then perhaps a more suitable protocol (IPPM OWAMP) should be used. Our chartered application is Network Configuration. > > >> Without specific features in the protocol which would >> need app-level ACKs (such as data model version negotiation), >> the cost and complexity of this feature cannot be justified. >> >> >... > >This is based on the premise that the sole reason for application >level acknowledgment is confirmation that it could "understand" >the data. For logging applications, this is neither necessary nor sufficient. > > NETCONF is not an accounting protocol. For network management, notifications are used for directed polling purposes. They are not intended to replace the reliable transfer of data via the direct request. This has been good enough for SNMP for years, so even if our charter was to replace SNMP (which it is not), this is not a feature that the NM community is currently using. If the agent has vital data that must not be lost, and must be understood by the NMS, then it should be designed to hold on to that data until the NMS retrieves it with an RPC call. Notifications should be used to tell the NMS to get the data. If this is not acceptable, the agent can open a session to the manager and use a reverse RPC to push the data. >Randy > > > 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 Nov 27 11:48:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgPhk-0001IF-Fu for netconf-archive@megatron.ietf.org; Sun, 27 Nov 2005 11:48:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04888 for ; Sun, 27 Nov 2005 11:48:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgPbJ-000DG2-G9 for netconf-data@psg.com; Sun, 27 Nov 2005 16:42:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1EgPbI-000DFq-On for netconf@ops.ietf.org; Sun, 27 Nov 2005 16:42:05 +0000 Received: (qmail 14304 invoked by uid 78); 27 Nov 2005 16:42:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.60 with SMTP; 27 Nov 2005 16:42:03 -0000 Message-ID: <4389E1E0.5050703@andybierman.com> Date: Sun, 27 Nov 2005 08:42:08 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Goddard CC: "Netconf (E-mail)" Subject: Re: NETCONF Notifications: Consensus Points References: <438758A3.6050603@andybierman.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ted Goddard wrote: > > On 25-Nov-05, at 11:32 AM, Andy Bierman wrote: > >> Feature Consistency at the Protocol Layer >> >> There is WG consensus that the protocol-level notification >> features must be consistent across the supported transports. >> However, there is not yet WG consensus that NETCONF over SOAP >> must be supported. The discussions have focused on SSH and BEEP. >> Each time it is mentioned that SOAP/HTTP cannot support this >> feature, the issue is ignored. > > > Notifications for NETCONF over SOAP/HTTP could be implemented > using: > > 1. Separate HTTP connections for NETCONF management and > NETCONF notifications channels You mean one session in each direction? Both NC peers have to implement HTTP Server and Client SW to have notifications in this case. > 2. HTTP response to a notification request delayed until > notifications are available Not sure what you mean here. I think you mean the NMS continuously polls for notifications, but the agent holds each response until there is a notification to send (in order to minimize the polling overhead). Won't this cause the connection to time out in the client, and perhaps HTTP caches in between the manager and agent? (I guess this can be avoided by using a different port number than 80.) > > Ted. 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 Sun Nov 27 13:12:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgR1E-0007QJ-2y for netconf-archive@megatron.ietf.org; Sun, 27 Nov 2005 13:12:56 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12282 for ; Sun, 27 Nov 2005 13:12:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgQuN-000Jg2-IJ for netconf-data@psg.com; Sun, 27 Nov 2005 18:05:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgQuM-000Jfm-Ve for netconf@ops.ietf.org; Sun, 27 Nov 2005 18:05:51 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 27 Nov 2005 10:05:51 -0800 X-IronPort-AV: i="3.97,381,1125903600"; d="scan'208"; a="370697428:sNHT25172976" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jARI5ms2015634; Sun, 27 Nov 2005 10:05:48 -0800 (PST) Received: from xmb-sjc-212.amer.cisco.com ([171.70.151.141]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 27 Nov 2005 10:05:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Notifications: Consensus Points Date: Sun, 27 Nov 2005 10:05:47 -0800 Message-ID: Thread-Topic: NETCONF Notifications: Consensus Points Thread-Index: AcXzGmsqDRStNYg9Q8GN3kA8T/XrLwAYlopw From: "Andrea Westerinen \(andreaw\)" To: "Randy Presuhn" , X-OriginalArrivalTime: 27 Nov 2005 18:05:48.0170 (UTC) FILETIME=[31C9D6A0:01C5F37D] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Randy, Don't hold back :-). I agree that in a high-delay environment that this would not be ideal - however, in a secure environment where you want to limit notifications or in a high-traffic/high-use environment, then it might make sense. Also, I did not indicate whether this was a synchronized ACK or ACKs could be batched or what the timing requirements were - just that this was one use by the sender of an ACK from the receiver. Andrea =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Randy Presuhn > Sent: Saturday, November 26, 2005 10:21 PM > To: netconf@ops.ietf.org > Subject: Re: NETCONF Notifications: Consensus Points >=20 > Hi - >=20 > > From: "Andrea Westerinen (andreaw)" > > To: "Randy Presuhn" ;=20 > > > > Sent: Saturday, November 26, 2005 9:42 PM > > Subject: RE: NETCONF Notifications: Consensus Points > > >=20 > > One usage of application-level ACKs (by the sender) is to disable=20 > > sending notifications/event messages until specifically re-enabled. > ... >=20 > That depends on how one structures the protocol. My initial=20 > reaction to > such a proposed usage is, in admittedly non-technical terms,=20 > "Eww, gross!" > More to the point, if the protocol only permits a single notification > "in the pipe" at a time, it would be unsuitable for use in=20 > high-delay (think NASA) > environments. Perhaps we can live with that; I don't know=20 > whether anyone > would use netconf in high-delay environments. >=20 > This is not a necessary property of application-level=20 > acknowledgements; > an example of a protocol that does not have this property is CMIP. >=20 > Randy >=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: From owner-netconf@ops.ietf.org Mon Nov 28 07:58:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgiaR-0001OS-1g for netconf-archive@megatron.ietf.org; Mon, 28 Nov 2005 07:58:27 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29831 for ; Mon, 28 Nov 2005 07:57:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgiOH-0008Yr-A5 for netconf-data@psg.com; Mon, 28 Nov 2005 12:45:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgiOF-0008YY-M7 for netconf@ops.ietf.org; Mon, 28 Nov 2005 12:45:51 +0000 Received: from pc6 (1Cust196.tnt110.lnd4.gbr.da.uu.net [62.188.174.196]) by galaxy.systems.pipex.net (Postfix) with SMTP id 61BCCE000260; Mon, 28 Nov 2005 12:45:42 +0000 (GMT) Message-ID: <01c701c5f410$ff0503e0$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Andy Bierman" , References: <438758A3.6050603@andybierman.com> Subject: terminolgy was Re: NETCONF Notifications: Consensus Points Date: Mon, 28 Nov 2005 12:41:47 +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 Content-Transfer-Encoding: 7bit Notification as a term I queried for two reasons, one being that I was unclear whether or not you were using it in the SNMPv3 sense, and I still don't know the answer. I see it used in security (PKI, EAP), CCAMP (probably borrowing from ITU-T), congestion (FECN) etc but only defined in SNMPv3. So I would like some clarification as to what you mean by it, as opposed to event message. You prefer the former but why, what distinction are you drawing? (My second reason is editorial, that event it used in so many places in the draft that I anticipate a lot of editing if notification is preferred to event) Tom Petch ----- Original Message ----- From: "Andy Bierman" To: Sent: Friday, November 25, 2005 7:32 PM Subject: NETCONF Notifications: Consensus Points > Hi, > > I'd like to try to gauge WG consensus on some recent > mailing list issues. Please object if you think I've > totally got it wrong: > > Terminology: > > The term Notification is preferred over Event Message. > > Max Message Size: > > A NETCONF peer should advertise its max message. > The standard should not set a max-size although it is > understood that implementations can use a max message size. > There seems to be some consensus for mandating a minimum > value for this parameter, although it's not clear what the exact > should be (something between 1500 and 65535 bytes). > > Application-Level ACKs > > It is not clear what a sender would do differently even > if it knew the receiver did not understand the message. > Without specific features in the protocol which would > need app-level ACKs (such as data model version negotiation), > the cost and complexity of this feature cannot be justified. > > Transport-Level ACKs > > There is WG consensus that this feature is required. > > Feature Consistency at the Protocol Layer > > There is WG consensus that the protocol-level notification > features must be consistent across the supported transports. > However, there is not yet WG consensus that NETCONF over SOAP > must be supported. The discussions have focused on SSH and BEEP. > Each time it is mentioned that SOAP/HTTP cannot support this > feature, the issue is ignored. > > Notification Info Model/Payload > > There is WG consensus to reuse syslog classification, although > the ability to transfer additional user data (similar to the OBJECTS > clause in an SNMP notification) is also required. The option > of asking the SYSLOG WG for enhancements to RFC 3195 is also > possible, and some WG members prefer this approach if syslog > is going to be enhanced in any meaningful way. > > Events Draft as Starting Point > > There is WG consensus to use draft-chisholm-netconf-event-01.txt as > the starting point for this work, even though there are strong > objections to specific details in the draft. It is understood > that the WG is addressing the feature list in the WG charter, > not in this draft, if the two are in conflict. > > > > -- > 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 Nov 28 09:45:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgkG8-0004j2-Np for netconf-archive@megatron.ietf.org; Mon, 28 Nov 2005 09:45:37 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13860 for ; Mon, 28 Nov 2005 09:44:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Egk6Y-000HpE-3g for netconf-data@psg.com; Mon, 28 Nov 2005 14:35:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1Egk6X-000Hp1-9H for netconf@ops.ietf.org; Mon, 28 Nov 2005 14:35:41 +0000 Received: (qmail 13382 invoked by uid 78); 28 Nov 2005 14:35:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.57 with SMTP; 28 Nov 2005 14:35:40 -0000 Message-ID: <438B15F9.2090205@andybierman.com> Date: Mon, 28 Nov 2005 06:36:41 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Petch CC: netconf@ops.ietf.org Subject: Re: terminolgy was Re: NETCONF Notifications: Consensus Points References: <438758A3.6050603@andybierman.com> <01c701c5f410$ff0503e0$0601a8c0@pc6> In-Reply-To: <01c701c5f410$ff0503e0$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tom Petch wrote: >Notification as a term I queried for two reasons, one being that I was unclear >whether or not you were using it in the SNMPv3 sense, and I still don't know the >answer. I see it used in security (PKI, EAP), CCAMP (probably borrowing from >ITU-T), congestion (FECN) etc but only defined in SNMPv3. > > I'm using the term as it was defined first in the English dictionary: http://www.m-w.com/dictionary/notification Function: noun 1 : the act or an instance of notifying 2 : a written or printed matter that gives notice >So I would like some clarification as to what you mean by it, as opposed to >event message. You prefer the former but why, what distinction are you drawing? > >(My second reason is editorial, that event it used in so many places in the >draft that I anticipate a lot of editing if notification is preferred to event) > > > This is not a WG draft. There will be many edits made if this becomes a WG draft. >Tom Petch > > > Andy >----- Original Message ----- >From: "Andy Bierman" >To: >Sent: Friday, November 25, 2005 7:32 PM >Subject: NETCONF Notifications: Consensus Points > > > > >>Hi, >> >>I'd like to try to gauge WG consensus on some recent >>mailing list issues. Please object if you think I've >>totally got it wrong: >> >>Terminology: >> >> The term Notification is preferred over Event Message. >> >>Max Message Size: >> >> A NETCONF peer should advertise its max message. >> The standard should not set a max-size although it is >> understood that implementations can use a max message size. >> There seems to be some consensus for mandating a minimum >> value for this parameter, although it's not clear what the exact >> should be (something between 1500 and 65535 bytes). >> >>Application-Level ACKs >> >> It is not clear what a sender would do differently even >> if it knew the receiver did not understand the message. >> Without specific features in the protocol which would >> need app-level ACKs (such as data model version negotiation), >> the cost and complexity of this feature cannot be justified. >> >>Transport-Level ACKs >> >> There is WG consensus that this feature is required. >> >>Feature Consistency at the Protocol Layer >> >> There is WG consensus that the protocol-level notification >> features must be consistent across the supported transports. >> However, there is not yet WG consensus that NETCONF over SOAP >> must be supported. The discussions have focused on SSH and BEEP. >> Each time it is mentioned that SOAP/HTTP cannot support this >> feature, the issue is ignored. >> >>Notification Info Model/Payload >> >> There is WG consensus to reuse syslog classification, although >> the ability to transfer additional user data (similar to the OBJECTS >> clause in an SNMP notification) is also required. The option >> of asking the SYSLOG WG for enhancements to RFC 3195 is also >> possible, and some WG members prefer this approach if syslog >> is going to be enhanced in any meaningful way. >> >>Events Draft as Starting Point >> >> There is WG consensus to use draft-chisholm-netconf-event-01.txt as >> the starting point for this work, even though there are strong >> objections to specific details in the draft. It is understood >> that the WG is addressing the feature list in the WG charter, >> not in this draft, if the two are in conflict. >> >> >> >>-- >>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 Mon Nov 28 10:44:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EglAk-0002cP-Pw for netconf-archive@megatron.ietf.org; Mon, 28 Nov 2005 10:44:07 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21832 for ; Mon, 28 Nov 2005 10:43:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Egkoo-000Lg3-Jn for netconf-data@psg.com; Mon, 28 Nov 2005 15:21:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Egkon-000Lfq-Hn for netconf@ops.ietf.org; Mon, 28 Nov 2005 15:21:26 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 306934C3B1; Mon, 28 Nov 2005 16:21:24 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 09971-04; Mon, 28 Nov 2005 16:21:22 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id A658F4C361; Mon, 28 Nov 2005 16:21:22 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id A86D8531192; Mon, 28 Nov 2005 16:21:22 +0100 (CET) Date: Mon, 28 Nov 2005 16:21:22 +0100 From: Juergen Schoenwaelder To: Andy Bierman Cc: Glenn Waters , netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points Message-ID: <20051128152122.GB7341@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , Glenn Waters , netconf@ops.ietf.org References: <085091CB2CA14E4B8B163FFC37C84E9D074BB495@zcarhxm0.corp.nortel.com> <4387817C.70209@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4387817C.70209@andybierman.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk On Fri, Nov 25, 2005 at 01:26:20PM -0800, Andy Bierman wrote: > >>Application-Level ACKs > >> > >> It is not clear what a sender would do differently even > >> if it knew the receiver did not understand the message. > >> Without specific features in the protocol which would > >> need app-level ACKs (such as data model version negotiation), > >> the cost and complexity of this feature cannot be justified. > >> > >> > > > >I think that we require Netconf Notification ACKs, and they can be > >optional as was done in SNMPv3 (i.e.: unACKed traps, ACKed informs). > >They are required for cases where the sender needs to know if the > >information was successful transmitted and may decide to retransmit at a > >later time. > > > > > > I'm not sure we are all clear on the semantics here. > What I think we mean by application-layer ACK > is the receiver understood the message. TCP lets > us know the receiver got the message. > > > I don't see how retransmitting at a later time will > help the receiver understand the message (delivered as sent) > any better, unless the reason the message was garbled is > an intermittent bug in the sender. I don't think we need to > worry about this case in the protocol. Because if this isn't the case, then > the exact same error condition will occur no matter how > many times the sender retries. My understanding is that a netconf protocol does not exist in isolation and that most events that trigger netconf notifications will originate in other pieces of software. For some pieces of software, "shout and forget" is all what is needed. Other applications may want to know whether they were heard so they can for example flush entries in notification logs (as Randy mentioned). If we don't provide application layer acks for those apps who need it, then these apps will end up using TCP acks as the only approximation for the indication that everything went fine. Such a best guess may work, but it surely is not what I would call a robust solution (but who cares about this these days). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Nov 28 10:59:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EglQ7-0006E7-G1 for netconf-archive@megatron.ietf.org; Mon, 28 Nov 2005 10:59:59 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23720 for ; Mon, 28 Nov 2005 10:59:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Egl9F-000Nj8-Lh for netconf-data@psg.com; Mon, 28 Nov 2005 15:42:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Egl9F-000Nia-09 for netconf@ops.ietf.org; Mon, 28 Nov 2005 15:42:33 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 28 Nov 2005 07:42:32 -0800 X-IronPort-AV: i="3.97,385,1125903600"; d="scan'208"; a="370976247:sNHT24355512" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jASFgWCJ019372; Mon, 28 Nov 2005 07:42:32 -0800 (PST) Received: from [212.254.247.3] (rtp-vpn2-390.cisco.com [10.82.241.134]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jASFoQvf032015; Mon, 28 Nov 2005 07:50:28 -0800 Message-ID: <438B2564.2060903@cisco.com> Date: Mon, 28 Nov 2005 16:42:28 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051025) MIME-Version: 1.0 To: Andy Bierman , Glenn Waters , netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points References: <085091CB2CA14E4B8B163FFC37C84E9D074BB495@zcarhxm0.corp.nortel.com> <4387817C.70209@andybierman.com> <20051128152122.GB7341@boskop.local> In-Reply-To: <20051128152122.GB7341@boskop.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=920; t=1133193029; x=1133625229; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20NETCONF=20Notifications=3A=20Consensus=20Points| From:Eliot=20Lear=20| Date:Mon,=2028=20Nov=202005=2016=3A42=3A28=20+0100| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=hcB+No2RMvQiF+H54ccTRjvHecwAjR4lX8p/xxIIo37t3rDENmW2HK3HJXTPz/62kIl278u2 r6ZjVXnZc99JSnhjyexklh+/EJV21Gj+dVKfUQ2rBdnqDjWRA6wzr2g9vglWi//eXMUXx8PWWLz 5xRgwcbvCvqHuvHNtTmUQvwE= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit To review, the times when one needs an "application level acknolwedgment" (ALA) is when the data has received and acknowledged by the sender, and further processing then fails. The classic example is a disk failure. Well, what comes next? If further processing fails does the receiver remain up or can it tear down the connection if its configuration dictates? If not, then ALAs are needed. If so, the other end has a signal that there is in fact a problem, and that it should follow its policy (for instance, going to backup server, re-establishing connection, what-have-you). At that point, if notifications are general in nature (e.g., not related to configuration, then one could argue that unless alarms are part of the architecture, ALAs will be needed because traipsing through device state searching for faults is probably cost prohibitive. If the notifications are related to configuration alone, will the new notification recipient be able to retrieve sufficient state to determine a configuration change in the device? If the answer is yes, then no ALAs are needed. Right or wrong? Eliot -- 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 Nov 28 11:21:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eglky-0002vx-Tz for netconf-archive@megatron.ietf.org; Mon, 28 Nov 2005 11:21:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26173 for ; Mon, 28 Nov 2005 11:20:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EglbG-0000oG-M9 for netconf-data@psg.com; Mon, 28 Nov 2005 16:11:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.54 (FreeBSD)) id 1EglbG-0000o5-8G for netconf@ops.ietf.org; Mon, 28 Nov 2005 16:11:30 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id jASGBTBm066608 for ; Mon, 28 Nov 2005 08:11:29 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jASGBT577849 for ; Mon, 28 Nov 2005 08:11:29 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id jASGGkYE010456 for ; Mon, 28 Nov 2005 11:16:46 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200511281616.jASGGkYE010456@idle.juniper.net> To: netconf@ops.ietf.org Subject: Tim Bray on RelaxNG Date: Mon, 28 Nov 2005 11:16:46 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk http://www1.ietf.org/mail-archive/web/xml-dir/current/msg00108.html As a general practice, I would advise the IETF to specify XML languages using the simpler, more general, more flexible, more interoperable RelaxNG, which is also an ISO standard by the way. For example, Atompub did this in draft-ietf-atompub-format-11, which is now a proposed standard and waiting for its RFC number. In particular, the kind of extensibility you want for XCON would be easily modeled in RelaxNG without the need for this kind of egregious kludge. -Tim Bray Can we revisit the use of Relax-NG for netconf (before we start resorting to egregious kludges ;^)? Thanks, Phil -- 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 Nov 28 11:34:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EglxZ-0007Kq-JD for netconf-archive@megatron.ietf.org; Mon, 28 Nov 2005 11:34:33 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27823 for ; Mon, 28 Nov 2005 11:33:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Egln6-0001lx-P8 for netconf-data@psg.com; Mon, 28 Nov 2005 16:23:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1Egln6-0001lk-1r for netconf@ops.ietf.org; Mon, 28 Nov 2005 16:23:44 +0000 Received: (qmail 28793 invoked by uid 78); 28 Nov 2005 16:23:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.62 with SMTP; 28 Nov 2005 16:23:43 -0000 Message-ID: <438B2F0C.4070605@andybierman.com> Date: Mon, 28 Nov 2005 08:23:40 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: Glenn Waters , netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points References: <085091CB2CA14E4B8B163FFC37C84E9D074BB495@zcarhxm0.corp.nortel.com> <4387817C.70209@andybierman.com> <20051128152122.GB7341@boskop.local> In-Reply-To: <20051128152122.GB7341@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: >On Fri, Nov 25, 2005 at 01:26:20PM -0800, Andy Bierman wrote: > > > >>>>Application-Level ACKs >>>> >>>>It is not clear what a sender would do differently even >>>>if it knew the receiver did not understand the message. >>>>Without specific features in the protocol which would >>>>need app-level ACKs (such as data model version negotiation), >>>>the cost and complexity of this feature cannot be justified. >>>> >>>> >>>> >>>> >>>I think that we require Netconf Notification ACKs, and they can be >>>optional as was done in SNMPv3 (i.e.: unACKed traps, ACKed informs). >>>They are required for cases where the sender needs to know if the >>>information was successful transmitted and may decide to retransmit at a >>>later time. >>> >>> >>> >>> >>I'm not sure we are all clear on the semantics here. >>What I think we mean by application-layer ACK >>is the receiver understood the message. TCP lets >>us know the receiver got the message. >> >> >>I don't see how retransmitting at a later time will >>help the receiver understand the message (delivered as sent) >>any better, unless the reason the message was garbled is >>an intermittent bug in the sender. I don't think we need to >>worry about this case in the protocol. Because if this isn't the case, then >>the exact same error condition will occur no matter how >>many times the sender retries. >> >> > >My understanding is that a netconf protocol does not exist in >isolation and that most events that trigger netconf notifications will >originate in other pieces of software. For some pieces of software, >"shout and forget" is all what is needed. Other applications may want >to know whether they were heard so they can for example flush entries >in notification logs (as Randy mentioned). > >If we don't provide application layer acks for those apps who need it, >then these apps will end up using TCP acks as the only approximation >for the indication that everything went fine. Such a best guess may >work, but it surely is not what I would call a robust solution (but >who cares about this these days). > > You are absolutely correct that this confirmation mechanism is needed -- and we already have it -- RPC. Define an rpc: and have the manager call it to ACK one or more notifications. If the 'ack-required' flag is set in the notification, then the agent will expect the manager to call this RPC, and if it does not, the agent can assume the manager didn't get it or understand it. >/js > > 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 Nov 28 11:38:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egm0w-00088c-5S for netconf-archive@megatron.ietf.org; Mon, 28 Nov 2005 11:38:57 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28230 for ; Mon, 28 Nov 2005 11:37:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EglpS-00020Q-8J for netconf-data@psg.com; Mon, 28 Nov 2005 16:26:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [64.40.101.249] (helo=www.icesoft.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EglpR-00020F-Lw for netconf@ops.ietf.org; Mon, 28 Nov 2005 16:26:09 +0000 Received: from [10.18.39.60] ([64.141.118.170]) by www.icesoft.com (Kerio MailServer 6.1.0) (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits)); Mon, 28 Nov 2005 08:26:39 -0800 In-Reply-To: <4389E1E0.5050703@andybierman.com> References: <438758A3.6050603@andybierman.com> <4389E1E0.5050703@andybierman.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "Netconf (E-mail)" Content-Transfer-Encoding: 7bit From: Ted Goddard Subject: Re: NETCONF Notifications: Consensus Points Date: Mon, 28 Nov 2005 09:26:06 -0700 To: Andy Bierman X-Mailer: Apple Mail (2.734) Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 27-Nov-05, at 9:42 AM, Andy Bierman wrote: > Ted Goddard wrote: >> Notifications for NETCONF over SOAP/HTTP could be implemented >> using: >> >> 1. Separate HTTP connections for NETCONF management and >> NETCONF notifications channels >> > > > You mean one session in each direction? > Both NC peers have to implement HTTP Server and Client SW > to have notifications in this case. The agent on the managed device would still be the HTTP server, but two normal HTTP connections would be opened to it from the NMS. Two connections are necessary because pipelining a notification request and a management request on the same connection could cause the management request to be blocked behind the notification. >> 2. HTTP response to a notification request delayed until >> notifications are available >> > > > Not sure what you mean here. > I think you mean the NMS continuously polls for notifications, > but the agent holds each response until there is a notification > to send (in order to minimize the polling overhead). Exactly; the agent does not respond to the request for notifications until notifications are available. Then if the NMS wants more, it asks again. It's not very elegant, but it does work within the confines of HTTP. > Won't this cause the connection to time out in the client, > and perhaps HTTP caches in between the manager and agent? > (I guess this can be avoided by using a different port number than > 80.) If there are caches or other factors causing timeouts, then I would suggest that the NMS should keep polling until the agent returns an error. But HTTP on the NMS could be configured to have a very long timeout, so the problem shouldn't really arise. Ted. >> >> -- >> 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 Mon Nov 28 11:46:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egm9T-0000s9-B1 for netconf-archive@megatron.ietf.org; Mon, 28 Nov 2005 11:46:51 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29362 for ; Mon, 28 Nov 2005 11:46:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Egm2T-0003ES-QU for netconf-data@psg.com; Mon, 28 Nov 2005 16:39:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Egm2S-0003EH-VJ for netconf@ops.ietf.org; Mon, 28 Nov 2005 16:39:37 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 28 Nov 2005 08:39:36 -0800 X-IronPort-AV: i="3.97,385,1125903600"; d="scan'208"; a="678932826:sNHT47797658" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jASGdWeU022923; Mon, 28 Nov 2005 08:39:34 -0800 (PST) Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 08:39:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: notification charter proposal Date: Mon, 28 Nov 2005 08:39:25 -0800 Message-ID: <6E21698722408147BEA594E073E2B0AB0105B9A6@xmb-sjc-223.amer.cisco.com> Thread-Topic: notification charter proposal Thread-Index: AcXxOtLkUs38Qg67Ruy6csiYNQCC1QAIwfFAALbnzFA= From: "Hector Trevino \(htrevino\)" To: "Sharon Chisholm" , X-OriginalArrivalTime: 28 Nov 2005 16:39:26.0591 (UTC) FILETIME=[4BBD60F0:01C5F43A] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Agree and as I said in a previous e-mail... a transport layer (TCP) ACK is sufficient for most applications. An application layer ACK could be included in the spec for those users who think they need it. I suggest that this should be separate of app layer protocol (e.g. BEEP) built-in acks. Hector -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm Sent: Thursday, November 24, 2005 6:19 PM To: netconf@ops.ietf.org Subject: RE: notification charter proposal hi No, they are not the same, but the transport layer one seems to be sufficient from what I have seen. I suggest we don't do anything to preclude the later addition of an application level acknowledgements, but that we don't provide one now. The design in the current draft does this. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of McDonald, Ira Sent: Thursday, November 24, 2005 3:58 PM To: netconf@ops.ietf.org Subject: RE: notification charter proposal Hi, As Juergen Schoenwaelder just pointed out - a transport layer ACK does NOT have the same semantics as an upper layer ACK that indicates receipt of a well-formed XML message. Confusing the two is not helpful - NetConf is supposed to behave the same over any transport. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Sharon Chisholm > Sent: Thursday, November 24, 2005 10:23 AM > To: netconf@ops.ietf.org > Subject: RE: notification charter proposal >=20 >=20 > hi >=20 > The only interest I saw historically in informs were from people who=20 > were disappointed we didn't run over TCP. After some investigation,=20 > people generally chose other means to maintain confidence that they=20 > were not loosing information. I just didn't see informs used in=20 > practice. >=20 > Given we now run over TCP, I have difficulty seeing people using=20 > acknowledged notifications in practice. The solution could be defined, > but I don't really know if there a lot of value in doing so. >=20 > Sharon >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Tuesday, November 22, 2005 9:32 AM > To: Waters, Glenn [CAR:IO47:EXCH] > Cc: Chisholm, Sharon [CAR:5K50:EXCH]; netconf@ops.ietf.org > Subject: Re: notification charter proposal >=20 >=20 > On Tue, Nov 22, 2005 at 09:00:20AM -0500, Glenn Waters wrote: >=20 > > > b) The notification sender sends a notification and gets a > confirmation > > > that the notification was understood to the extend > that it could > be > > > handed over to an entity dealing with notifications. (This is > what > > > SNMP notifications actually do.) > >=20 > > I don't think that there is enough value in sending a > response in this >=20 > > case since there is little recourse the sender can take to > correct the >=20 > > issue. There is the possibility the sender could reduce the message=20 > > size but that can be handled in other ways (such as the receiver=20 > > reconfiguring the max size the sender should send). I can't > think of > > what else a sender would possibly do with a response. Maybe > it would > > help to identify those items to help decide if a response would be=20 > > useful. >=20 > Knowledge of the fact that you were not understood can be very useful, > even if you do not know how to make yourself understood. >=20 > You are arguing from a very narrow protocol centric perspective and I=20 > agree that from this protocol centric perspective there is hardly=20 > something you can do. However, if you take a more system wide=20 > perspective, then I think one can easily make a case for b) and even=20 > for c). >=20 > Note: I am not against a) nor am I against b) and c) - it is just=20 > important for me that once we talk about adding notifications, we=20 > better be clear what their semantics are and which role they can play=20 > in a systems view. >=20 > /js >=20 > PS: There are also strong ties here to notification logging (see the > NOTIFICATION-LOG-MIB produced by the DISMAN WG). The information > whether a notification was "understood" can actually be used to > decide what remains in a log and what can be purged. Without such > information, the notification originator actually has to log=20 > everything (and maybe rely on the receiver to clear log entries). >=20 > --=20 > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, > Germany >=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 Mon Nov 28 12:02:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgmOT-0004dr-Fq for netconf-archive@megatron.ietf.org; Mon, 28 Nov 2005 12:02:21 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01445 for ; Mon, 28 Nov 2005 12:01:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgmCY-00045r-OF for netconf-data@psg.com; Mon, 28 Nov 2005 16:50:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgmCX-00045U-Uq for netconf@ops.ietf.org; Mon, 28 Nov 2005 16:50:01 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 28 Nov 2005 08:50:01 -0800 X-IronPort-AV: i="3.97,385,1125903600"; d="scan'208"; a="371013693:sNHT108870648" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jASGnps8029837; Mon, 28 Nov 2005 08:49:58 -0800 (PST) Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 08:49:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: notification charter proposal Date: Mon, 28 Nov 2005 08:49:53 -0800 Message-ID: <6E21698722408147BEA594E073E2B0AB0105B9C1@xmb-sjc-223.amer.cisco.com> Thread-Topic: notification charter proposal Thread-Index: AcXwzXXao/a3iTkqRleLxhZ/UGLYQgDbPpdg From: "Hector Trevino \(htrevino\)" To: "Eliot Lear" , "Andy Bierman" Cc: "Glenn Waters" , , "Phil Shafer" , "Sharon Chisholm" , X-OriginalArrivalTime: 28 Nov 2005 16:49:53.0887 (UTC) FILETIME=[C1A326F0:01C5F43B] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Comments in-line (HT) Hector =20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Eliot Lear Sent: Thursday, November 24, 2005 12:59 AM To: Andy Bierman Cc: Glenn Waters; j.schoenwaelder@iu-bremen.de; Phil Shafer; Sharon Chisholm; netconf@ops.ietf.org Subject: Re: notification charter proposal Andy, I hope you're enjoying some decent Bird today in America and don't actually read this till later ;-) Please see below. Andy Bierman wrote: > I agree with Juergen on this one. I agree in part. I do not want the tail to wag the dog. Just because SSH or BEEP does or doesn't have a feature shouldn't dictate the approach to notifications (events, whatever..). > I would like to make sure the mandatory transport (SSH) can be used=20 > for all the notification features defined. First, if the notification feature is not mandatory, you're probably adding extra unwanted hair. But if we go this route, let's make proper use of mapping mechanisms. If SSH needs to add an ACK that's already there for BEEP, don't make BEEP have a 2nd unnecessary ACK. Now putting the horse before the cart, I think we have a few problems in this space. First of all, there is the SYSLOG working group that is currently attempting to finalize a new specification that will include some amount of structured data. We must not simply duplicate their work in an incompatible way, and so I agree with you there. HT: Same here & Appendix D was put in as an attempt to address this issue However, SYSLOG isn't much more than PRI+Date+host+text. There's a lot of room to do better than that. I think Sharon and crew should be thinking about one of two directions: - what to do with the structured text component contemplated by SYSLOG wg (and now's the time to talk to them - and I mean right now) - creating a second approach that is richer than what SYSLOG has. The good here is that event systems have been out there for a while, and so perhaps the time is ripe. The bad is that many have tried... HT: We are trying to do a combination of the two above. There are some good things about syslog which could/should be preserved but as I think everyone agrees, syslog has limitations and there is no reason why a second approach as you call it can't be pursued. More specifically to your first point, the appendix in the doc does not discuss how to maintain structured data definitions in sync but we have looked at this issue. The latest syslog-protocol draft only has 2-3 definitions thus far.=20 So I don't know which approach is correct. Finally, I reiterate that events and notifications appear to be architecturally severable, and so I would like to understand why it is necessary for the netconf protocol to be extended beyond perhaps a capability referencing other work. Eliot -- 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 Nov 28 12:25:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egmkc-00045O-Hw for netconf-archive@megatron.ietf.org; Mon, 28 Nov 2005 12:25:14 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05268 for ; Mon, 28 Nov 2005 12:24:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgmYb-0005uk-TQ for netconf-data@psg.com; Mon, 28 Nov 2005 17:12:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgmYb-0005uM-3R for netconf@ops.ietf.org; Mon, 28 Nov 2005 17:12:49 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 227B04C09C; Mon, 28 Nov 2005 18:12:48 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 24237-10; Mon, 28 Nov 2005 18:12:46 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id CFFBB65AD; Mon, 28 Nov 2005 18:12:46 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id ABF6553130F; Mon, 28 Nov 2005 18:12:44 +0100 (CET) Date: Mon, 28 Nov 2005 18:12:44 +0100 From: Juergen Schoenwaelder To: Andy Bierman Cc: Glenn Waters , netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points Message-ID: <20051128171244.GA7672@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , Glenn Waters , netconf@ops.ietf.org References: <085091CB2CA14E4B8B163FFC37C84E9D074BB495@zcarhxm0.corp.nortel.com> <4387817C.70209@andybierman.com> <20051128152122.GB7341@boskop.local> <438B2F0C.4070605@andybierman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438B2F0C.4070605@andybierman.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de Sender: owner-netconf@ops.ietf.org Precedence: bulk On Mon, Nov 28, 2005 at 08:23:40AM -0800, Andy Bierman wrote: > > You are absolutely correct that this confirmation mechanism > is needed -- and we already have it -- RPC. > > Define an rpc: and have the manager call it > to ACK one or more notifications. If the 'ack-required' flag > is set in the notification, then the agent will expect the manager > to call this RPC, and if it does not, the agent can assume the manager > didn't get it or understand it. > A poor soul asked for an ACK, you try to sell him an ACK which will lead to another ACK. Why not give him what he asked for, an ACK? If NETCONF server wants to send an acknowleged notification, then the notification is sent via an element which will be acknowledged by an element. If a NETCONF server wants to send an unacknowledged notification, then it uses the yet to be defined and agreed one-way RPC mechanism. What is wrong with that? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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 Nov 28 12:41:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egn0I-00011x-Bf for netconf-archive@megatron.ietf.org; Mon, 28 Nov 2005 12:41:26 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07492 for ; Mon, 28 Nov 2005 12:40:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Egmln-0006pZ-6m for netconf-data@psg.com; Mon, 28 Nov 2005 17:26:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Egmlm-0006pM-E9 for netconf@ops.ietf.org; Mon, 28 Nov 2005 17:26:26 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 28 Nov 2005 09:26:26 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jASHQ9sC018677; Mon, 28 Nov 2005 09:26:24 -0800 (PST) Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 09:26:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Size matters was Re: notification charter proposal Date: Mon, 28 Nov 2005 09:26:10 -0800 Message-ID: <6E21698722408147BEA594E073E2B0AB0105B9F2@xmb-sjc-223.amer.cisco.com> Thread-Topic: Size matters was Re: notification charter proposal Thread-Index: AcXxmbDwOLnVKhMMQK+vsZifjNjLpgCpt4Lg From: "Hector Trevino \(htrevino\)" To: "Balazs Lengyel" Cc: X-OriginalArrivalTime: 28 Nov 2005 17:26:11.0753 (UTC) FILETIME=[D3BF2190:01C5F440] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I agree w/what you're saying and I wasn't suggesting setting max. message sizes. Also, just talking about notifications.=20 Hector =20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel Sent: Friday, November 25, 2005 1:22 AM Cc: netconf@ops.ietf.org Subject: Re: Size matters was Re: notification charter proposal Please dont set a max message size generally for netconf !!! For me one attractive usage of netconf would be to retrieve the complete configuration of a node. If we set a mandatory max-size for all netconf messages (as opposed to setting it for notifications only) this usage would become impossible. For big nodes it is anyone's guess what the size of a full configuration can be. We have nodes that contain the data of 10 million subscribers. Balazs Lengyel Ericsson Hungary Ltd. Hector Trevino (htrevino) wrote: >=20 > I agree that this is part of the protocol definition but I see it as=20 > outside the scope of the charter definition. I'd assume none of this=20 > will be included in the charter. >=20 >=20 > I don't think the spec should set a hard limit on the max message size. > I agree w/Juergen about not limiting the protocol but rather allowing=20 > implementations to advertise their max message sizes (if one is set).=20 > It may be better to say something like app layer message segmentation=20 > is not allowed. But recommendations/guidelines for max message sizes=20 > should be provided in the spec. >=20 > Hector >=20 > =20 > =20 >=20 > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]=20 > On Behalf Of Andy Bierman > Sent: Tuesday, November 22, 2005 4:01 PM > To: Tom Petch > Cc: netconf@ops.ietf.org > Subject: Re: Size matters was Re: notification charter proposal >=20 > Tom Petch wrote: >=20 >=20 >> >>Tom Petch >>----- Original Message ----- >>From: "Andy Bierman" >>To: >>Cc: "Tom Petch" ; >>Sent: Tuesday, November 22, 2005 4:41 PM >>Subject: Re: notification charter proposal > > >>=20 >> >> >>>That would be fine with me. >>>I brought up the issue because the problem is obviously worse for=20 >>>notifications than RPCs, because the lack of an application layer ACK >>>(which effectively is). >>> >>>The reason for setting a minimum is to allow NMS developers to code=20 >>>to >=20 >=20 >>>some reasonable minimum. The market will help keep things somewhat=20 >>>reasonable, but we could see a range from 1500 to 64K as the minimum. >=20 >=20 >>>Is that OK? >>> >>>Andy >>> >>> =20 >>> >> >>I raised size because there are references appearing on the list=20 >>calling for something syslog-like and size has been an issue with=20 >>syslog that has not been satisfactorily resolved. syslog unearthed=20 >>two >=20 >=20 >>contrasting viewpoints, one that messages should not exceed 2k or even >>1k, the other that 64k should be supported (for at least one >=20 > application). >=20 >>Netconf is more virgin territory than syslog is but I do believe is=20 >>setting a Maximum size, at least to start with; but I do not see this=20 >>as anything to do with the charter:-). >>=20 >> >=20 >=20 > This is part of protocol syntax and semantics. >=20 > IMO, the best approach is to have the NC peer advertise its=20 > max-message-size. The number should be an PositiveInteger, so that=20 > would set a theoretical max-message-size of 4G-1 bytes. >=20 >=20 > A separate issue is whether there is a minimum an NC peer can set this > parameter to, somewhat higher than zero. I don't see any consensus=20 > yet on how much higher to set the minimum. >=20 >=20 > Another important issue: Can an NC peer (optionally?) send its=20 > max-message-size in the exchange? This doesn't mean the other > NC peer has to do anything with the value, it just provides a good=20 > guess at the number instead of trying > various message sizes to see what breaks. Advertising a > max-message-size doesn't mean you won't get messages greater than that > size. >=20 >=20 >=20 >>Tom Petch >> >> >>=20 >> >=20 >=20 > Andy >=20 >=20 >>=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 Mon Nov 28 15:16:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgpQn-0005n9-2O for netconf-archive@megatron.ietf.org; Mon, 28 Nov 2005 15:16:57 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29565 for ; Mon, 28 Nov 2005 15:16:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgpJX-000JI4-RB for netconf-data@psg.com; Mon, 28 Nov 2005 20:09:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1EgpJW-000JHU-OR for netconf@ops.ietf.org; Mon, 28 Nov 2005 20:09:26 +0000 Received: (qmail 12631 invoked by uid 78); 28 Nov 2005 20:09:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.62 with SMTP; 28 Nov 2005 20:09:25 -0000 Message-ID: <438B63F3.9020304@andybierman.com> Date: Mon, 28 Nov 2005 12:09:23 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hector Trevino (htrevino)" CC: Sharon Chisholm , netconf@ops.ietf.org Subject: Re: notification charter proposal References: <6E21698722408147BEA594E073E2B0AB0105B9A6@xmb-sjc-223.amer.cisco.com> In-Reply-To: <6E21698722408147BEA594E073E2B0AB0105B9A6@xmb-sjc-223.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hector Trevino (htrevino) wrote: >Agree and as I said in a previous e-mail... a transport layer (TCP) ACK >is sufficient for most applications. An application layer ACK could be >included in the spec for those users who think they need it. I suggest >that this should be separate of app layer protocol (e.g. BEEP) built-in >acks. > > Do you mean an optional-to-implement ACK feature? Or optional-to-use ACK feature? What is this mechanism exactly? Don't care because you mean optional-to-implement and don't plan on implementing it? Nobody has specified the messages, timeouts, state machine, etc. It's more complicated than "throw in an ACK". IMO it is bad engineering to build this complexity into the protocol if it's not important enough to be mandatory to implement. Please see my previous email on the RPC idea. I don't see why we would spend a lot of effort on a complicated optional-to-implement solution when we already have a mandatory solution available. The RPC and setting the ack-required flag in the message could be optional to implement or support. But this is just another RPC, and there is no need to define a complicated architecture because RPC is already defined. BTW, this provides a 3-way confirm, not 2-way like an application ACK. Since the agent replies to the RPC request, the manager knows that the agent got the application ACK. >Hector > > Andy > > >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Sharon Chisholm >Sent: Thursday, November 24, 2005 6:19 PM >To: netconf@ops.ietf.org >Subject: RE: notification charter proposal > >hi > >No, they are not the same, but the transport layer one seems to be >sufficient from what I have seen. I suggest we don't do anything to >preclude the later addition of an application level acknowledgements, >but that we don't provide one now. The design in the current draft does >this. > >Sharon > >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of McDonald, Ira >Sent: Thursday, November 24, 2005 3:58 PM >To: netconf@ops.ietf.org >Subject: RE: notification charter proposal > > >Hi, > >As Juergen Schoenwaelder just pointed out - a transport layer ACK does >NOT have the same semantics as an upper layer ACK that indicates receipt >of a well-formed XML message. > >Confusing the two is not helpful - NetConf is supposed to behave the >same over any transport. > >Cheers, >- Ira > > >Ira McDonald (Musician / Software Architect) Blue Roof Music / High >North Inc PO Box 221 Grand Marais, MI 49839 >phone: +1-906-494-2434 >email: imcdonald@sharplabs.com > > > >>-----Original Message----- >>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On >>Behalf Of Sharon Chisholm >>Sent: Thursday, November 24, 2005 10:23 AM >>To: netconf@ops.ietf.org >>Subject: RE: notification charter proposal >> >> >>hi >> >>The only interest I saw historically in informs were from people who >>were disappointed we didn't run over TCP. After some investigation, >>people generally chose other means to maintain confidence that they >>were not loosing information. I just didn't see informs used in >>practice. >> >>Given we now run over TCP, I have difficulty seeing people using >>acknowledged notifications in practice. The solution could be defined, >> >> > > > >>but I don't really know if there a lot of value in doing so. >> >>Sharon >> >>-----Original Message----- >>From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] >>Sent: Tuesday, November 22, 2005 9:32 AM >>To: Waters, Glenn [CAR:IO47:EXCH] >>Cc: Chisholm, Sharon [CAR:5K50:EXCH]; netconf@ops.ietf.org >>Subject: Re: notification charter proposal >> >> >>On Tue, Nov 22, 2005 at 09:00:20AM -0500, Glenn Waters wrote: >> >> >> >>>>b) The notification sender sends a notification and gets a >>>> >>>> >>confirmation >> >> >>>> that the notification was understood to the extend >>>> >>>> >>that it could >>be >> >> >>>> handed over to an entity dealing with notifications. (This is >>>> >>>> >>what >> >> >>>> SNMP notifications actually do.) >>>> >>>> >>>I don't think that there is enough value in sending a >>> >>> >>response in this >> >> >> >>>case since there is little recourse the sender can take to >>> >>> >>correct the >> >> >> >>>issue. There is the possibility the sender could reduce the message >>>size but that can be handled in other ways (such as the receiver >>>reconfiguring the max size the sender should send). I can't >>> >>> >>think of >> >> >>>what else a sender would possibly do with a response. Maybe >>> >>> >>it would >> >> >>>help to identify those items to help decide if a response would be >>>useful. >>> >>> >>Knowledge of the fact that you were not understood can be very useful, >> >> > > > >>even if you do not know how to make yourself understood. >> >>You are arguing from a very narrow protocol centric perspective and I >>agree that from this protocol centric perspective there is hardly >>something you can do. However, if you take a more system wide >>perspective, then I think one can easily make a case for b) and even >>for c). >> >>Note: I am not against a) nor am I against b) and c) - it is just >>important for me that once we talk about adding notifications, we >>better be clear what their semantics are and which role they can play >>in a systems view. >> >>/js >> >>PS: There are also strong ties here to notification logging (see the >> NOTIFICATION-LOG-MIB produced by the DISMAN WG). The information >> whether a notification was "understood" can actually be used to >> decide what remains in a log and what can be purged. Without such >> information, the notification originator actually has to log >> everything (and maybe rely on the receiver to clear log entries). >> >>-- >>Juergen Schoenwaelder International University Bremen >> P.O. Box 750 561, >>28725 Bremen, >>Germany >> >> >>-- >>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: > >-- >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 Nov 28 15:22:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgpWU-0007hO-7o for netconf-archive@megatron.ietf.org; Mon, 28 Nov 2005 15:22:50 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00277 for ; Mon, 28 Nov 2005 15:22:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgpMG-000JTR-DY for netconf-data@psg.com; Mon, 28 Nov 2005 20:12:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.55] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1EgpMF-000JTG-Me for netconf@ops.ietf.org; Mon, 28 Nov 2005 20:12:15 +0000 Received: (qmail 6113 invoked from network); 28 Nov 2005 20:12:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.115 with SMTP; 28 Nov 2005 20:12:14 -0000 Message-ID: <438B649C.7040401@andybierman.com> Date: Mon, 28 Nov 2005 12:12:12 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: Glenn Waters , netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points References: <085091CB2CA14E4B8B163FFC37C84E9D074BB495@zcarhxm0.corp.nortel.com> <4387817C.70209@andybierman.com> <20051128152122.GB7341@boskop.local> <438B2F0C.4070605@andybierman.com> <20051128171244.GA7672@boskop.local> In-Reply-To: <20051128171244.GA7672@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: >On Mon, Nov 28, 2005 at 08:23:40AM -0800, Andy Bierman wrote: > > >>You are absolutely correct that this confirmation mechanism >>is needed -- and we already have it -- RPC. >> >>Define an rpc: and have the manager call it >>to ACK one or more notifications. If the 'ack-required' flag >>is set in the notification, then the agent will expect the manager >>to call this RPC, and if it does not, the agent can assume the manager >>didn't get it or understand it. >> >> >> > >A poor soul asked for an ACK, you try to sell him an ACK which will >lead to another ACK. Why not give him what he asked for, an ACK? > > If NETCONF server wants to send an acknowleged notification, then > the notification is sent via an element which will be > acknowledged by an element. If a NETCONF server wants > to send an unacknowledged notification, then it uses the yet to > be defined and agreed one-way RPC mechanism. > >What is wrong with that? > > Because I don't think it is good engineering to add a lot of complexity for an optional-to-implement feature. There is way too much of that "kitchen-sink" approach in the IETF. Let's make it mandatory for everybody to implement if it's worth having. How many people still want it then? >/js > > > 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 Nov 28 15:50:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egpxc-0008TY-68 for netconf-archive@megatron.ietf.org; Mon, 28 Nov 2005 15:50:52 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03734 for ; Mon, 28 Nov 2005 15:50:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgppM-000ND6-Sl for netconf-data@psg.com; Mon, 28 Nov 2005 20:42:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,DATE_IN_FUTURE_12_24 autolearn=no version=3.1.0 Received: from [64.233.184.207] (helo=wproxy.gmail.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgppM-000NCj-43 for netconf@ops.ietf.org; Mon, 28 Nov 2005 20:42:20 +0000 Received: by wproxy.gmail.com with SMTP id i23so2470709wra for ; Mon, 28 Nov 2005 12:42:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:reply-to:from:to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:importance:x-mimeole; b=LwhCBRJLTB9xKGhUZBcMo+G3RJl+LRCz9lEtkKJnnAvLhLsx5rxQlQqW7fJxFuhYSAoGw3G7UlinAAOUdnq0wdqkOTBbmZHrW5QoA5ltZ4KD8j5o2xFw1pzEGRyn5ugAja1CJtebBmLhFMtAcgjtpnQiMY8BktRUj7aymSn4W1g= Received: by 10.64.220.2 with SMTP id s2mr3725391qbg; Mon, 28 Nov 2005 12:42:18 -0800 (PST) Received: from JPHOMEPC ( [80.133.44.7]) by mx.gmail.com with ESMTP id q19sm700397qbq.2005.11.28.12.42.17; Mon, 28 Nov 2005 12:42:18 -0800 (PST) Reply-To: From: "Jayaprakash Kulkarni \(Wipro\)" To: Subject: RE: notification charter proposal Date: Tue, 29 Nov 2005 22:32:53 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit NETCONF over SOAP is a candidate which would need Notification acknowledgement. Since SOAP can be implemented over UDP too. Notifications acknowledgement for parallel notifications can be costly to implement in some devices with limited memory. Should we have notifications-acknowledgement as a capability? regards Jayaprakash Wipro Technologies -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Sharon Chisholm Sent: Thursday, November 24, 2005 6:19 PM To: netconf@ops.ietf.org Subject: RE: notification charter proposal hi No, they are not the same, but the transport layer one seems to be sufficient from what I have seen. I suggest we don't do anything to preclude the later addition of an application level acknowledgements, but that we don't provide one now. The design in the current draft does this. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of McDonald, Ira Sent: Thursday, November 24, 2005 3:58 PM To: netconf@ops.ietf.org Subject: RE: notification charter proposal Hi, As Juergen Schoenwaelder just pointed out - a transport layer ACK does NOT have the same semantics as an upper layer ACK that indicates receipt of a well-formed XML message. Confusing the two is not helpful - NetConf is supposed to behave the same over any transport. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Sharon Chisholm > Sent: Thursday, November 24, 2005 10:23 AM > To: netconf@ops.ietf.org > Subject: RE: notification charter proposal > > > hi > > The only interest I saw historically in informs were from people who > were disappointed we didn't run over TCP. After some investigation, > people generally chose other means to maintain confidence that they > were not loosing information. I just didn't see informs used in > practice. > > Given we now run over TCP, I have difficulty seeing people using > acknowledged notifications in practice. The solution could be defined, > but I don't really know if there a lot of value in doing so. > > Sharon > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Tuesday, November 22, 2005 9:32 AM > To: Waters, Glenn [CAR:IO47:EXCH] > Cc: Chisholm, Sharon [CAR:5K50:EXCH]; netconf@ops.ietf.org > Subject: Re: notification charter proposal > > > On Tue, Nov 22, 2005 at 09:00:20AM -0500, Glenn Waters wrote: > > > > b) The notification sender sends a notification and gets a > confirmation > > > that the notification was understood to the extend > that it could > be > > > handed over to an entity dealing with notifications. (This is > what > > > SNMP notifications actually do.) > > > > I don't think that there is enough value in sending a > response in this > > > case since there is little recourse the sender can take to > correct the > > > issue. There is the possibility the sender could reduce the message > > size but that can be handled in other ways (such as the receiver > > reconfiguring the max size the sender should send). I can't > think of > > what else a sender would possibly do with a response. Maybe > it would > > help to identify those items to help decide if a response would be > > useful. > > Knowledge of the fact that you were not understood can be very useful, > even if you do not know how to make yourself understood. > > You are arguing from a very narrow protocol centric perspective and I > agree that from this protocol centric perspective there is hardly > something you can do. However, if you take a more system wide > perspective, then I think one can easily make a case for b) and even > for c). > > Note: I am not against a) nor am I against b) and c) - it is just > important for me that once we talk about adding notifications, we > better be clear what their semantics are and which role they can play > in a systems view. > > /js > > PS: There are also strong ties here to notification logging (see the > NOTIFICATION-LOG-MIB produced by the DISMAN WG). The information > whether a notification was "understood" can actually be used to > decide what remains in a log and what can be purged. Without such > information, the notification originator actually has to log > everything (and maybe rely on the receiver to clear log entries). > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, > Germany > > > -- > 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: -- 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 Nov 28 16:04:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgqBD-0005HZ-1e for netconf-archive@megatron.ietf.org; Mon, 28 Nov 2005 16:04:55 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08259 for ; Mon, 28 Nov 2005 16:04:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Egq3W-000PHM-Qn for netconf-data@psg.com; Mon, 28 Nov 2005 20:56:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Egq3V-000PGz-Ov for netconf@ops.ietf.org; Mon, 28 Nov 2005 20:56:57 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 28 Nov 2005 12:56:58 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jASKuVeq016281; Mon, 28 Nov 2005 12:56:55 -0800 (PST) Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 12:56:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: notification charter proposal Date: Mon, 28 Nov 2005 12:56:54 -0800 Message-ID: <6E21698722408147BEA594E073E2B0AB0105BB75@xmb-sjc-223.amer.cisco.com> Thread-Topic: notification charter proposal Thread-Index: AcX0V6u6nVyirHLdSr2NWfOGgs0BeQAASgZg From: "Hector Trevino \(htrevino\)" To: "Andy Bierman" Cc: "Sharon Chisholm" , X-OriginalArrivalTime: 28 Nov 2005 20:56:55.0138 (UTC) FILETIME=[43CA9420:01C5F45E] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com]=20 Sent: Monday, November 28, 2005 1:09 PM To: Hector Trevino (htrevino) Cc: Sharon Chisholm; netconf@ops.ietf.org Subject: Re: notification charter proposal Hector Trevino (htrevino) wrote: >Agree and as I said in a previous e-mail... a transport layer (TCP) ACK >is sufficient for most applications. An application layer ACK could be=20 >included in the spec for those users who think they need it. I suggest=20 >that this should be separate of app layer protocol (e.g. BEEP) built-in >acks. > =20 > Do you mean an optional-to-implement ACK feature? Or optional-to-use ACK feature? HT: I meant an optional-to-use ACK feature. However, thus far notifications are optional (another capability). =20 What is this mechanism exactly? Don't care because you mean optional-to-implement and don't plan on implementing it? HT: No, we haven't discussed the mechanism because the current document proposes NO appl layer ACKs. Some people want to have appl layer ACKs. If there is enough support and justification for this additional functionality then we could specify it.=20 Nobody has specified the messages, timeouts, state machine, etc. It's more complicated than "throw in an ACK". IMO it is bad engineering to build this complexity into the protocol if it's not important enough to be mandatory to implement. HT: Sure, agree. =20 Please see my previous email on the RPC idea. I don't see why we would spend a lot of effort on a complicated optional-to-implement solution when we already have a mandatory solution available.=20 The RPC and setting the ack-required flag in the message could be optional to implement or support. But this is just another RPC, and there is no need to define a complicated architecture because RPC is already defined. BTW, this provides a 3-way confirm, not 2-way like an application ACK.=20 Since the agent replies to the RPC request, the manager knows that the agent got the application ACK. HT: I saw that and it is certainly a possibility. The current doc introduces rpc-one-way (for unackd notifications). You could use the existing rpc-request, rpc-reply for ackd notifications. I guess depending on where the ack has to be originated what you're proposing may be better but at an extra ACK expense. =20 >Hector > =20 > Andy > > >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of Sharon Chisholm >Sent: Thursday, November 24, 2005 6:19 PM >To: netconf@ops.ietf.org >Subject: RE: notification charter proposal > >hi > >No, they are not the same, but the transport layer one seems to be=20 >sufficient from what I have seen. I suggest we don't do anything to=20 >preclude the later addition of an application level acknowledgements,=20 >but that we don't provide one now. The design in the current draft does >this. > >Sharon > >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On >Behalf Of McDonald, Ira >Sent: Thursday, November 24, 2005 3:58 PM >To: netconf@ops.ietf.org >Subject: RE: notification charter proposal > > >Hi, > >As Juergen Schoenwaelder just pointed out - a transport layer ACK does=20 >NOT have the same semantics as an upper layer ACK that indicates=20 >receipt of a well-formed XML message. > >Confusing the two is not helpful - NetConf is supposed to behave the=20 >same over any transport. > >Cheers, >- Ira > > >Ira McDonald (Musician / Software Architect) Blue Roof Music / High=20 >North Inc PO Box 221 Grand Marais, MI 49839 >phone: +1-906-494-2434 >email: imcdonald@sharplabs.com > > =20 > >>-----Original Message----- >>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On >>Behalf Of Sharon Chisholm >>Sent: Thursday, November 24, 2005 10:23 AM >>To: netconf@ops.ietf.org >>Subject: RE: notification charter proposal >> >> >>hi >> >>The only interest I saw historically in informs were from people who=20 >>were disappointed we didn't run over TCP. After some investigation,=20 >>people generally chose other means to maintain confidence that they=20 >>were not loosing information. I just didn't see informs used in=20 >>practice. >> >>Given we now run over TCP, I have difficulty seeing people using=20 >>acknowledged notifications in practice. The solution could be defined, >> =20 >> > > =20 > >>but I don't really know if there a lot of value in doing so. >> >>Sharon >> >>-----Original Message----- >>From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] >>Sent: Tuesday, November 22, 2005 9:32 AM >>To: Waters, Glenn [CAR:IO47:EXCH] >>Cc: Chisholm, Sharon [CAR:5K50:EXCH]; netconf@ops.ietf.org >>Subject: Re: notification charter proposal >> >> >>On Tue, Nov 22, 2005 at 09:00:20AM -0500, Glenn Waters wrote: >> >> =20 >> >>>>b) The notification sender sends a notification and gets a >>>> =20 >>>> >>confirmation >> =20 >> >>>> that the notification was understood to the extend >>>> =20 >>>> >>that it could >>be >> =20 >> >>>> handed over to an entity dealing with notifications. (This is >>>> =20 >>>> >>what >> =20 >> >>>> SNMP notifications actually do.) >>>> =20 >>>> >>>I don't think that there is enough value in sending a >>> =20 >>> >>response in this >> >> =20 >> >>>case since there is little recourse the sender can take to >>> =20 >>> >>correct the >> >> =20 >> >>>issue. There is the possibility the sender could reduce the message=20 >>>size but that can be handled in other ways (such as the receiver=20 >>>reconfiguring the max size the sender should send). I can't >>> =20 >>> >>think of >> =20 >> >>>what else a sender would possibly do with a response. Maybe >>> =20 >>> >>it would >> =20 >> >>>help to identify those items to help decide if a response would be=20 >>>useful. >>> =20 >>> >>Knowledge of the fact that you were not understood can be very useful, >> =20 >> > > =20 > >>even if you do not know how to make yourself understood. >> >>You are arguing from a very narrow protocol centric perspective and I=20 >>agree that from this protocol centric perspective there is hardly=20 >>something you can do. However, if you take a more system wide=20 >>perspective, then I think one can easily make a case for b) and even=20 >>for c). >> >>Note: I am not against a) nor am I against b) and c) - it is just=20 >>important for me that once we talk about adding notifications, we=20 >>better be clear what their semantics are and which role they can play=20 >>in a systems view. >> >>/js >> >>PS: There are also strong ties here to notification logging (see the >> NOTIFICATION-LOG-MIB produced by the DISMAN WG). The information >> whether a notification was "understood" can actually be used to >> decide what remains in a log and what can be purged. Without such >> information, the notification originator actually has to log=20 >> everything (and maybe rely on the receiver to clear log entries). >> >>--=20 >>Juergen Schoenwaelder International University Bremen >> P.O. Box 750 561,=20 >>28725 Bremen, >>Germany >> >> >>-- >>to unsubscribe send a message to netconf-request@ops.ietf.org with the >> =20 >> > > =20 > >>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=20 >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=20 >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=20 >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: From owner-netconf@ops.ietf.org Tue Nov 29 00:52:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgyPa-0005hO-Dj for netconf-archive@megatron.ietf.org; Tue, 29 Nov 2005 00:52:18 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16222 for ; Tue, 29 Nov 2005 00:51:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgyGV-000Afn-EM for netconf-data@psg.com; Tue, 29 Nov 2005 05:42:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.127.202.56] (helo=sccrmhc12.comcast.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgyGS-000Afa-UI for netconf@ops.ietf.org; Tue, 29 Nov 2005 05:42:53 +0000 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc12) with SMTP id <2005112905424701200b3jk1e>; Tue, 29 Nov 2005 05:42:47 +0000 Reply-To: From: "David B Harrington" To: "'Phil Shafer'" , Subject: RE: Tim Bray on RelaxNG Date: Tue, 29 Nov 2005 00:42:39 -0500 Message-ID: <02c501c5f4a7$b865c400$0400a8c0@DJYXPY41> 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.2180 Thread-Index: AcX0N82eLv+bTks7QLSRMr/cz92U1AAb9G7g In-Reply-To: <200511281616.jASGGkYE010456@idle.juniper.net> Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I prefer egregious kludges; call it job security ;) (just kidding, of course) dbh > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Phil Shafer > Sent: Monday, November 28, 2005 11:17 AM > To: netconf@ops.ietf.org > Subject: Tim Bray on RelaxNG > > http://www1.ietf.org/mail-archive/web/xml-dir/current/msg00108.html > > As a general practice, I would advise the IETF to specify XML > languages using the simpler, more general, more flexible, more > interoperable RelaxNG, which is also an ISO standard by the > way. For example, Atompub did this in > draft-ietf-atompub-format-11, > which is now a proposed standard and waiting for its RFC number. > In particular, the kind of extensibility you want for XCON would > be easily modeled in RelaxNG without the need for this kind of > egregious kludge. -Tim Bray > > > Can we revisit the use of Relax-NG for netconf (before we start > resorting to egregious kludges ;^)? > > Thanks, > Phil > > -- > 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 Tue Nov 29 01:06:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgydB-0002bQ-0X for netconf-archive@megatron.ietf.org; Tue, 29 Nov 2005 01:06:21 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17335 for ; Tue, 29 Nov 2005 01:05:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgyY3-000C62-Bo for netconf-data@psg.com; Tue, 29 Nov 2005 06:01:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgyY2-000C5r-TC for netconf@ops.ietf.org; Tue, 29 Nov 2005 06:01:02 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 28 Nov 2005 22:01:02 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAT610eS001570; Mon, 28 Nov 2005 22:01:00 -0800 (PST) Received: from [212.254.247.5] (ams-clip-vpn-dhcp61.cisco.com [10.61.64.61]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jAT68r7l006426; Mon, 28 Nov 2005 22:08:54 -0800 Message-ID: <438BEE9A.6030302@cisco.com> Date: Tue, 29 Nov 2005 07:00:58 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051025) MIME-Version: 1.0 To: jayaprakash.kulkarni@gmail.com CC: netconf@ops.ietf.org Subject: Re: notification charter proposal References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=500; t=1133244534; x=1133676734; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20notification=20charter=20proposal| From:Eliot=20Lear=20| Date:Tue,=2029=20Nov=202005=2007=3A00=3A58=20+0100| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=l9+DJW7JU21SCwU23s4xhV5NdbdvmWBwfkDNzhQg9jE2hT3K23KRxzpPihn0vMndlRld1MnY CXT0d5gOpz7+hRzvRaiwgwD6yjFkEe4eQRbaZHSaWKe+/DvS7j0t+gtzfAv2TYKD5Thh8eI/YnZ XJ5PQmZGWqRkjxhWN4pdkB94= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jayaprakash Kulkarni (Wipro) wrote: > NETCONF over SOAP is a candidate which would need Notification > acknowledgement. > Since SOAP can be implemented over UDP too. > > Notifications acknowledgement for parallel notifications can be costly to > implement in some devices with limited memory. > > Should we have notifications-acknowledgement as a capability? > That's not an argument for acknowledgment. Section 2.1 of draft-ietf-netconf-proto states that NETCONF expects a reliable transport. Any unreliable transport must be dealt with in the mapping and not in the core protocol. Eliot -- 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 Nov 29 10:11:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh78g-0005f8-61 for netconf-archive@megatron.ietf.org; Tue, 29 Nov 2005 10:11:26 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17711 for ; Tue, 29 Nov 2005 10:10:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eh6wu-000EgB-PS for netconf-data@psg.com; Tue, 29 Nov 2005 14:59:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [47.140.192.55] (helo=zrtps0kn.nortelnetworks.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eh6wu-000Efx-0z for netconf@ops.ietf.org; Tue, 29 Nov 2005 14:59:16 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jATExBA24571 for ; Tue, 29 Nov 2005 09:59:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Notifications: Consensus Points Date: Tue, 29 Nov 2005 09:59:05 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B405ED354A@zcarhxm2.corp.nortel.com> Thread-Topic: NETCONF Notifications: Consensus Points Thread-Index: AcXx8IjyZhv9wwYnSOCkAl4vmamrWQDA2RmQ From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Notification Info Model/Payload There is WG consensus to reuse syslog classification, although the ability to transfer additional user data (similar to the OBJECTS clause in an SNMP notification) is also required. The option of asking the SYSLOG WG for enhancements to RFC 3195 is also possible, and some WG members prefer this approach if syslog is going to be enhanced in any meaningful way. This one I think requires more discussion before we can declare some consensus. I think there is a general sense that there is something from the land of syslog that we want to take advantage of and learn from, but I have not seen strong consensus as to what that is. And which version of syslog are people looking to leverage?=20 I think being able to tunnel syslog content into netconf is good for transitioning and our internet draft discusses this a bit in one of the appendices. What is more interesting though, is some of the SD-Params we have developed in syslog. I think bringing these in, not using SD-Param grammar, but as properly tagged XML would be very very useful. Sharon -- 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 Nov 29 11:54:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh8k7-0007yO-V9 for netconf-archive@megatron.ietf.org; Tue, 29 Nov 2005 11:54:12 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02694 for ; Tue, 29 Nov 2005 11:53:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eh8Yd-000KMR-Co for netconf-data@psg.com; Tue, 29 Nov 2005 16:42:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1Eh8Yc-000KME-KR for netconf@ops.ietf.org; Tue, 29 Nov 2005 16:42:18 +0000 Received: (qmail 31328 invoked by uid 78); 29 Nov 2005 16:42:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.55 with SMTP; 29 Nov 2005 16:42:05 -0000 Message-ID: <438C84DC.5050201@andybierman.com> Date: Tue, 29 Nov 2005 08:42:04 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points References: <713043CE8B8E1348AF3C546DBE02C1B405ED354A@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B405ED354A@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sharon Chisholm wrote: > >Notification Info Model/Payload > > There is WG consensus to reuse syslog classification, although > the ability to transfer additional user data (similar to the OBJECTS > clause in an SNMP notification) is also required. The option > of asking the SYSLOG WG for enhancements to RFC 3195 is also > possible, and some WG members prefer this approach if syslog > is going to be enhanced in any meaningful way. > > >This one I think requires more discussion before we can declare some >consensus. I think there is a general sense that there is something from >the land of syslog that we want to take advantage of and learn from, but >I have not seen strong consensus as to what that is. And which version >of syslog are people looking to leverage? > >I think being able to tunnel syslog content into netconf is good for >transitioning and our internet draft discusses this a bit in one of the >appendices. What is more interesting though, is some of the SD-Params we >have developed in syslog. I think bringing these in, not using SD-Param >grammar, but as properly tagged XML would be very very useful. > > > I think this WG is a little better at discussing detailed text than abstract concepts. I suppose we will know which fields people agree on when we get down in the details and hammer out every option of every feature from top to bottom and back again. So go ahead and write up details for SD-Params if you want. At this point there isn't WG consensus for any particular field of any message over any transport. However several people have expressed concern over reinventing syslog or SNMP Notifications, and this will be a factor in the process. >Sharon > > 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 Tue Nov 29 12:27:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh9G1-0006X4-Rd for netconf-archive@megatron.ietf.org; Tue, 29 Nov 2005 12:27:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08272 for ; Tue, 29 Nov 2005 12:26:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eh983-000Mfb-6j for netconf-data@psg.com; Tue, 29 Nov 2005 17:18:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eh982-000MfI-8c for netconf@ops.ietf.org; Tue, 29 Nov 2005 17:18:54 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 29 Nov 2005 09:18:54 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jATHIMPJ019737; Tue, 29 Nov 2005 09:18:51 -0800 (PST) Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Nov 2005 09:18:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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 Notifications: Consensus Points Date: Tue, 29 Nov 2005 09:18:46 -0800 Message-ID: <6E21698722408147BEA594E073E2B0AB0105BDD6@xmb-sjc-223.amer.cisco.com> Thread-Topic: NETCONF Notifications: Consensus Points Thread-Index: AcX1BC66kveuhw3jQ0aUyb7UDdjyMQAAyDRA From: "Hector Trevino \(htrevino\)" To: "Andy Bierman" , "Sharon Chisholm" Cc: X-OriginalArrivalTime: 29 Nov 2005 17:18:48.0626 (UTC) FILETIME=[F6091120:01C5F508] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable The last appendix in the netconf-event doc has a list of proposed syslog fields which could be re-used. The syslog-draft has only 3 SD-IDs defined thus far. Left them out of the write-up for now since there needs to be some description of how these fields are adopted for use and how they are maintained in sync w/the syslog work. Also, is the reverse true (i.e. if the equivalent of SD-IDs are defined for NETCONF are they then introduced into syslog?). We have looked at some of this at Cisco and it seems to be a good idea (SD-ID equivalence) but haven't worked out all the details.=20 Hector =20 =20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Tuesday, November 29, 2005 9:42 AM To: Sharon Chisholm Cc: netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points Sharon Chisholm wrote: > >Notification Info Model/Payload > > There is WG consensus to reuse syslog classification, although > the ability to transfer additional user data (similar to the OBJECTS > clause in an SNMP notification) is also required. The option > of asking the SYSLOG WG for enhancements to RFC 3195 is also > possible, and some WG members prefer this approach if syslog > is going to be enhanced in any meaningful way. > > >This one I think requires more discussion before we can declare some=20 >consensus. I think there is a general sense that there is something=20 >from the land of syslog that we want to take advantage of and learn=20 >from, but I have not seen strong consensus as to what that is. And=20 >which version of syslog are people looking to leverage? > >I think being able to tunnel syslog content into netconf is good for=20 >transitioning and our internet draft discusses this a bit in one of the >appendices. What is more interesting though, is some of the SD-Params=20 >we have developed in syslog. I think bringing these in, not using=20 >SD-Param grammar, but as properly tagged XML would be very very useful. > > =20 > I think this WG is a little better at discussing detailed text than abstract concepts. I suppose we will know which fields people agree on when we get down in the details and hammer out every option of every feature from top to bottom and back again. So go ahead and write up details for SD-Params if you want. At this point there isn't WG consensus for any particular field of any message over any transport.=20 However several people have expressed concern over reinventing syslog or SNMP Notifications, and this will be a factor in the process. >Sharon > =20 > Andy >-- >to unsubscribe send a message to netconf-request@ops.ietf.org with the=20 >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 Tue Nov 29 17:14:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhDkZ-00077B-Bg for netconf-archive@megatron.ietf.org; Tue, 29 Nov 2005 17:14:59 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17240 for ; Tue, 29 Nov 2005 17:14:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhDbv-000Fql-5k for netconf-data@psg.com; Tue, 29 Nov 2005 22:06:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [204.127.202.55] (helo=sccrmhc11.comcast.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EhDbu-000Fqa-Ec for netconf@ops.ietf.org; Tue, 29 Nov 2005 22:06:02 +0000 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc11) with SMTP id <2005112922060101100hhujee>; Tue, 29 Nov 2005 22:06:01 +0000 Reply-To: From: "David B Harrington" To: Subject: RE: NETCONF Notifications: Consensus Points Date: Tue, 29 Nov 2005 17:05:58 -0500 Message-ID: <034201c5f531$1403c080$0400a8c0@DJYXPY41> 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.2180 Thread-Index: AcX0NMwfH6xm3qH0RXWfL+OGyBUB6AAAUqNQ In-Reply-To: <438B2564.2060903@cisco.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I personally prefer "notification" to "event message" because I would like to see consistency in the terminology used for IETF O&M protocols. There seem to be three variations - notification, event notification, and event message; everywhere event notification is used, the same document also refers to it simply as a notification, and no document seems to identify what other type of notification besides event notification is possible. Here's my research on the use of "notification" vs. "event message" in O&M documents: "notification" - SNMP (rfc3413), IPFIX requirements (rfc3917), Diameter (rfc3588), Syslog (rfc3164), Opsec Practices (draft-ietf-opsec-current-practices-02) "event message" - Syslog (rfc3164), netconf (draft-chisholm-netconf-event-01.txt) Widening this to a search of RFCs which use notification or event in their title, and checking for "notification" or "event message" in the text of the document: "notification" - Simple New Mail Notification (rfc4146), Requirements for IPP Notifications (rfc3997), Internet Printing Protocol (IPP): Event Notifications and Subscriptions (rfc3995), The SPIRITS (Services in PSTN requesting Internet Services) Protocol (rfc3910), A Presence Event Package for the Session Initiation Protocol (SIP) (rfc3856), Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP) (rfc3503), An Extensible Message Format for Delivery Status Notifications (rfc3464), Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) (rfc3461), Session Initiation Protocol (SIP)-Specific Event Notification (rfc3265), The Addition of Explicit Congestion Notification (ECN) to IP (rfc3168), An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP) (rfc4235), Session Initiation Protocol (SIP) Extension for Event State Publication (rfc3903), etc. "event message" - Nuff said? David Harrington dbharrington@comcast.net -- 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 Nov 29 17:27:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhDww-0006fg-R7 for netconf-archive@megatron.ietf.org; Tue, 29 Nov 2005 17:27:49 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18622 for ; Tue, 29 Nov 2005 17:27:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhDpp-000GnQ-6e for netconf-data@psg.com; Tue, 29 Nov 2005 22:20:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.54 (FreeBSD)) id 1EhDpo-000Gn3-Ih for netconf@ops.ietf.org; Tue, 29 Nov 2005 22:20:24 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id jATMKE000368; Tue, 29 Nov 2005 14:20:14 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jATMK8577063; Tue, 29 Nov 2005 14:20:08 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id jATMPPYE016052; Tue, 29 Nov 2005 17:25:25 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200511292225.jATMPPYE016052@idle.juniper.net> To: "Sharon Chisholm" cc: netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points In-Reply-To: Your message of "Tue, 29 Nov 2005 09:59:05 EST." <713043CE8B8E1348AF3C546DBE02C1B405ED354A@zcarhxm2.corp.nortel.com> Date: Tue, 29 Nov 2005 17:25:25 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk "Sharon Chisholm" writes: >I think bringing these in, not using SD-Param >grammar, but as properly tagged XML would be very very useful. XML has its uses, but log data is not one of them. We need to be careful that we don't start seeing everything as a nail to our xml hammer. XML is useful for encoding hierarchical data, but is horrible for simple flat data (try encoding a csv file in xml). XML is good at encoding data that is highly variable, but expensive for more normalizable data. XML is great for data interchange, where both sides of the conversation need to be flexible and resilient. But it's horrible for data storage. XML's overhead can be ignored for intermittent operations like configuration requests, but will kill you at high volume. Compare a notification in XML: RPD_RSVP_NBRUP my-host rpd 10.5.14.2 fe-1/3/0.0 RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0 and the same data in syslog: Oct 18 16:01:37 my-host rpd[2958]: RPD_RSVP_NBRUP: RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0 The syslog-SD form of this would be something like: 1 888 4 00 2005-10-18-16:01:37 my-host rpd 2958 RPD_RSVP_NBRUP [JNPR-0 neighbor="10.5.14.2" interface="fe-1/3/0.0"] RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0 (That should be close enough; I'm not an SD-guru) wc -c reports the lengths as 321, 104, and 168. I take it as a given that customers will use notification data from netconf in the same pattern we see with syslog data. They configure large volumes of data, which they store and use to investigate problems, either real-time or port-mortem. IMHO, the SD-PARAM version wins hands down, based on functionality .vs. footprint. I can filter by severity, date, msgid, and message content parameters. That's pretty much all I'm after. Thanks, Phil -- 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 Nov 29 21:13:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhHTC-00048l-No for netconf-archive@megatron.ietf.org; Tue, 29 Nov 2005 21:13:18 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11085 for ; Tue, 29 Nov 2005 21:12:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhHJU-0002o3-Iw for netconf-data@psg.com; Wed, 30 Nov 2005 02:03:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FUZZY_VLIUM autolearn=no version=3.1.0 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EhHJU-0002np-1Q for netconf@ops.ietf.org; Wed, 30 Nov 2005 02:03:16 +0000 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by kremlin.juniper.net with ESMTP; 29 Nov 2005 18:03:15 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,193,1131350400"; d="scan'208"; a="513042866:sNHT24398332" Received: from photon.jnpr.net ([172.24.18.198]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Nov 2005 18:03:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: IANA considerations update for NETCONF protocol draft Date: Tue, 29 Nov 2005 18:02:37 -0800 Message-ID: <062B922B6EC55149B5A267ECE78E5D440D30C92F@photon.jnpr.net> Thread-Topic: IANA considerations update for NETCONF protocol draft Thread-Index: AcX1UiNUqEcgi2RBRbm6NJJNS5FWKg== From: "Rob Enns" To: X-OriginalArrivalTime: 30 Nov 2005 02:03:14.0988 (UTC) FILETIME=[3972DEC0:01C5F552] Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable The IANA review of the protocol draft raised some questions on how to handle review of the spec for new capabilities. Based on those questions and input from Andy, here's a proposed update to the IANA considerations section that requests 2 different registries for NETCONF capabilities: - the first would be for IETF standardized capabilities, and would require IETF consensus for new capabilities - the second would be for enterprise capabilities, and would be first come first served, with a specification required Could the WG review this and comment? thanks, Rob ------------------ 10.3. NETCONF Capability URNs This document requests that IANA create a registry for allocating NETCONF capability identifiers. Allocation from the registry requires a specification and IETF consensus (approval by the NETCONF working group or a follow-on working group). The initial content of the registry will be the capability URNs defined in Section 8. Once further experience is gained with NETCONF, this sub-namespace may be used for additional purposes. Following the guidelines in RFC 3553 [7], IANA is requested to assign a NETCONF sub-namespace as follows: Registry name: netconf Specification: Section 8 of this document. Repository: The following table. +--------------------+----------------------------------------------+ | Index | Capability Identifier | +--------------------+----------------------------------------------+ | :writable-running | urn:ietf:params:netconf:capability:writable- | | | running:1.0 | | :candidate | urn:ietf:params:netconf:capability:candidate | | | :1.0 | | :confirmed-commit | urn:ietf:params:netconf:capability:confirmed | | | -commit:1.0 | | :rollback-on-error | urn:ietf:params:netconf:capability:rollback- | | | on-error:1.0 | | :validate | urn:ietf:params:netconf:capability:validate: | | | 1.0 | | :startup | urn:ietf:params:netconf:capability:startup:1 | | | .0 | | :url | urn:ietf:params:netconf:capability:url:1.0 | | :xpath | urn:ietf:params:netconf:capability:xpath:1.0 | +--------------------+----------------------------------------------+ Index value: The capability name. 10.4. NETCONF Enterprise Capability URNs This document requests that IANA create a registry for allocating NETCONF capability identifiers to enterprises. Allocation from the registry is on a First Come First Served basis, but a specification is required in the form of Appendix C of this document. Following the guidelines in RFC 3553 [7], IANA is requested to assign a NETCONF sub-namespace as follows: Registry name: netconf-enterprise Specification: To be provided by the registrant. The specification document must conform to Appendix C of this document. Repository: IANA is requested to store the submitted specifications in a public location such as http://www.iana.org/assignments/netconf/capabilities.html. Index value: The capability name.=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 Wed Nov 30 02:57:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhMqU-0006HG-5j for netconf-archive@megatron.ietf.org; Wed, 30 Nov 2005 02:57:42 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11484 for ; Wed, 30 Nov 2005 02:56:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhMf3-000LHN-Ct for netconf-data@psg.com; Wed, 30 Nov 2005 07:45:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EhMf0-000LH0-Dq for netconf@ops.ietf.org; Wed, 30 Nov 2005 07:45:50 +0000 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 33963F7A for ; Wed, 30 Nov 2005 08:45:49 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 08:45:26 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 08:45:25 +0100 Message-ID: <438D5895.2060900@ericsson.com> Date: Wed, 30 Nov 2005 08:45:25 +0100 From: Balazs Lengyel User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points References: <200511292225.jATMPPYE016052@idle.juniper.net> In-Reply-To: <200511292225.jATMPPYE016052@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Nov 2005 07:45:26.0014 (UTC) FILETIME=[06E4D1E0:01C5F582] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As the draft already indicated there are multiple reasons to send a notification. For information messages where the manager's main activity is just to store the content a concise format is the way to go. On the other hand a fault or maintenance type notification might result in further processing and actions so these should be kept in a structured XML format. Balazs Phil Shafer wrote: > "Sharon Chisholm" writes: > >>I think bringing these in, not using SD-Param >>grammar, but as properly tagged XML would be very very useful. > > > XML has its uses, but log data is not one of them. We need to be > careful that we don't start seeing everything as a nail to our xml > hammer. > > XML is useful for encoding hierarchical data, but is horrible for > simple flat data (try encoding a csv file in xml). XML is good at > encoding data that is highly variable, but expensive for more > normalizable data. XML is great for data interchange, where both > sides of the conversation need to be flexible and resilient. But > it's horrible for data storage. XML's overhead can be ignored for > intermittent operations like configuration requests, but will kill > you at high volume. > > Compare a notification in XML: > > > > RPD_RSVP_NBRUP > my-host > rpd > > 10.5.14.2 > fe-1/3/0.0 > > RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0 > > > and the same data in syslog: > > Oct 18 16:01:37 my-host rpd[2958]: RPD_RSVP_NBRUP: RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0 > > The syslog-SD form of this would be something like: > > 1 888 4 00 2005-10-18-16:01:37 my-host rpd 2958 RPD_RSVP_NBRUP [JNPR-0 neighbor="10.5.14.2" interface="fe-1/3/0.0"] RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0 > > (That should be close enough; I'm not an SD-guru) > > wc -c reports the lengths as 321, 104, and 168. > > I take it as a given that customers will use notification data from > netconf in the same pattern we see with syslog data. They configure > large volumes of data, which they store and use to investigate > problems, either real-time or port-mortem. > > IMHO, the SD-PARAM version wins hands down, based on functionality > .vs. footprint. I can filter by severity, date, msgid, and message > content parameters. That's pretty much all I'm after. > > Thanks, > Phil > > -- > 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 Wed Nov 30 10:47:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhUBU-0003ki-1T for netconf-archive@megatron.ietf.org; Wed, 30 Nov 2005 10:47:53 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02277 for ; Wed, 30 Nov 2005 10:47:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhU1F-000OQu-AF for netconf-data@psg.com; Wed, 30 Nov 2005 15:37:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.54 (FreeBSD)) id 1EhU1C-000OQg-KB for netconf@ops.ietf.org; Wed, 30 Nov 2005 15:37:14 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id jAUFbC016188; Wed, 30 Nov 2005 07:37:12 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jAUFb7519494; Wed, 30 Nov 2005 07:37:07 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id jAUFgKYE018302; Wed, 30 Nov 2005 10:42:23 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200511301542.jAUFgKYE018302@idle.juniper.net> To: Balazs Lengyel cc: netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points In-Reply-To: Your message of "Wed, 30 Nov 2005 08:45:25 +0100." <438D5895.2060900@ericsson.com> Date: Wed, 30 Nov 2005 10:42:20 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Balazs Lengyel writes: >On the other hand a fault or maintenance type notification might result in further >processing and actions so these should be kept in a structured XML format. What does XML give you here that SD wouldn't? Thanks, Phil -- 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 Wed Nov 30 11:33:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhUu4-0003bL-7S for netconf-archive@megatron.ietf.org; Wed, 30 Nov 2005 11:33:56 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07523 for ; Wed, 30 Nov 2005 11:33:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhUnP-0001oK-N7 for netconf-data@psg.com; Wed, 30 Nov 2005 16:27:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [205.178.146.50] (helo=mail.networksolutionsemail.com) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1EhUnK-0001ns-KJ for netconf@ops.ietf.org; Wed, 30 Nov 2005 16:26:58 +0000 Received: (qmail 20362 invoked by uid 78); 30 Nov 2005 16:26:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by 10.49.34.65 with SMTP; 30 Nov 2005 16:26:18 -0000 Message-ID: <438DD2B1.2030601@andybierman.com> Date: Wed, 30 Nov 2005 08:26:25 -0800 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phil Shafer CC: Balazs Lengyel , netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points References: <200511301542.jAUFgKYE018302@idle.juniper.net> In-Reply-To: <200511301542.jAUFgKYE018302@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Phil Shafer wrote: >Balazs Lengyel writes: > > >>On the other hand a fault or maintenance type notification might result in further >>processing and actions so these should be kept in a structured XML format. >> >> > >What does XML give you here that SD wouldn't? > > An encoding that a wide variety of tools support for NMS development. That is the rationale that got us started with XML in the first place. It is important to lots of people. However, I sort of agree with you. The history of tools development is one of putting up with the deficiencies of the "current approach" until something better comes along. In this case, all XML buys you is the encoding of the individual message fields, which is a small fraction of the work needed to do anything interesting with the data (I submit that a log-dumper doesn't qualify as interesting). But -- this is a lot more than nothing -- if you don't really care about the 2X or 3X in encoding size overhead. I wonder if the "dual syntax" approach of RelaxNG (XML and Compact syntax) would work here? Sharon's suggestion of an XML format could coexist with this one, if someone did all the work to spec it out. The problem with your theory is the premise that people using XML care about encoding and transfer efficiency. It would hard to come up with a syntax that was more verbose or more complicated to encode/decode than XML. It's not built for speed. (Not built for comfort either ;-) >Thanks, > Phil > > 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 Wed Nov 30 11:49:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhV9E-0005q3-H4 for netconf-archive@megatron.ietf.org; Wed, 30 Nov 2005 11:49:36 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09183 for ; Wed, 30 Nov 2005 11:48:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhV2I-0002vn-QK for netconf-data@psg.com; Wed, 30 Nov 2005 16:42:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.54 (FreeBSD)) id 1EhV2F-0002va-7w for netconf@ops.ietf.org; Wed, 30 Nov 2005 16:42:23 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id jAUGgA019236; Wed, 30 Nov 2005 08:42:10 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jAUGg4534967; Wed, 30 Nov 2005 08:42:04 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id jAUGlLYE018699; Wed, 30 Nov 2005 11:47:22 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-Id: <200511301647.jAUGlLYE018699@idle.juniper.net> To: Andy Bierman cc: Balazs Lengyel , netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points In-Reply-To: Your message of "Wed, 30 Nov 2005 08:26:25 PST." <438DD2B1.2030601@andybierman.com> Date: Wed, 30 Nov 2005 11:47:21 -0500 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk Andy Bierman writes: >The problem with your theory is the premise that people using XML care about >encoding and transfer efficiency. Well, my theory is that operators save lots of log data and won't be happy about a 3x xml tax. They then inspect log files, where filtering is invaluable. They want the juice, but in a cheaper form. Syslog w/ SD-Params fills the need without filling your log servers. FWIW, I take it as a given that they'll go crazy over SD data, but that's a point that should be verified. I know I'm drooling over it. >It's not built for speed. (Not built for comfort either ;-) Yup, Willie Dixon would not be caught dead playing with XML. Thanks, Phil -- 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 Wed Nov 30 11:57:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhVGw-0003yb-Ak for netconf-archive@megatron.ietf.org; Wed, 30 Nov 2005 11:57:35 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10248 for ; Wed, 30 Nov 2005 11:56:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhVCx-0003kd-95 for netconf-data@psg.com; Wed, 30 Nov 2005 16:53:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EhVCq-0003k7-5H for netconf@ops.ietf.org; Wed, 30 Nov 2005 16:53:20 +0000 X-TACSUNS: Virus Scanned Received: from rtp-cse-133.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jAUGrJL25896; Wed, 30 Nov 2005 11:53:19 -0500 (EST) Received: from localhost (chelliot@localhost) by rtp-cse-133.cisco.com (8.11.7p1+Sun/8.11.6) with ESMTP id jAUGrIc18642; Wed, 30 Nov 2005 11:53:18 -0500 (EST) Date: Wed, 30 Nov 2005 11:53:18 -0500 (EST) From: Chris Elliott To: Phil Shafer cc: Andy Bierman , Balazs Lengyel , netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points In-Reply-To: <200511301647.jAUGlLYE018699@idle.juniper.net> Message-ID: References: <200511301647.jAUGlLYE018699@idle.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-netconf@ops.ietf.org Precedence: bulk On Wed, 30 Nov 2005, Phil Shafer wrote: > Andy Bierman writes: >> The problem with your theory is the premise that people using XML care about >> encoding and transfer efficiency. > > Well, my theory is that operators save lots of log data and won't > be happy about a 3x xml tax. They then inspect log files, where > filtering is invaluable. They want the juice, but in a cheaper > form. Syslog w/ SD-Params fills the need without filling your > log servers. CPU is still considerably cheaper than disk in most cases, so compress the files. My experience leads me to believe that both formats will compress to a at least close to the same size. As far a efficiency over the wire, network management traffic is such a small fraction of the total these days that I don't think anyone's too worried about increasing it, even a fair amount. I'd rather not have to deal with two formats--and, yes, certain apps will have to deal with both formats and will have to try to resolve what a particular SD-Param relates to in XML, or the SNMP MIB, or CLI...We have enough formats already. Chris. > FWIW, I take it as a given that they'll go crazy over SD data, but > that's a point that should be verified. I know I'm drooling over it. > >> It's not built for speed. (Not built for comfort either ;-) > > Yup, Willie Dixon would not be caught dead playing with XML. > > Thanks, > Phil > > -- > 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: > Chris Elliott CCIE# 2013 | | Customer Diagnostic Engineer ||| ||| RTP, NC, USA ||||| ||||| 919-392-2146 .:|||||||||:|||||||||:. chelliot@cisco.com c i s c o S y s t e m s -- 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 Wed Nov 30 12:11:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhVUK-0007IQ-P7 for netconf-archive@megatron.ietf.org; Wed, 30 Nov 2005 12:11:24 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11853 for ; Wed, 30 Nov 2005 12:10:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhVNo-0004V8-0n for netconf-data@psg.com; Wed, 30 Nov 2005 17:04:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [63.240.77.81] (helo=sccrmhc11.comcast.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EhVNj-0004Up-BY for netconf@ops.ietf.org; Wed, 30 Nov 2005 17:04:35 +0000 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc11) with SMTP id <20051130170433011005tsf5e>; Wed, 30 Nov 2005 17:04:33 +0000 Reply-To: From: "David B Harrington" To: "'Chris Elliott'" , "'Phil Shafer'" Cc: "'Andy Bierman'" , "'Balazs Lengyel'" , Subject: RE: NETCONF Notifications: Consensus Points Date: Wed, 30 Nov 2005 12:04:22 -0500 Message-ID: <039e01c5f5d0$20135df0$0400a8c0@DJYXPY41> 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.2180 Thread-Index: AcX1zysYago1F5uTSpCWtp1lM7fs0QAANhrw In-Reply-To: Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Chris Elliott > > I'd rather not have to deal with two formats--and, yes, > certain apps will > have to deal with both formats and will have to try to resolve what a > particular SD-Param relates to in XML, or the SNMP MIB, or > CLI...We have > enough formats already. > I concur David Harrington dbharrington@comcast.net -- 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 Wed Nov 30 14:38:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXn6-0006nH-Bm for netconf-archive@megatron.ietf.org; Wed, 30 Nov 2005 14:38:56 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02369 for ; Wed, 30 Nov 2005 14:38:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhXfS-000ElZ-8U for netconf-data@psg.com; Wed, 30 Nov 2005 19:31:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EhXfN-000ElI-CB for netconf@ops.ietf.org; Wed, 30 Nov 2005 19:30:57 +0000 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B60F94F0019; Wed, 30 Nov 2005 17:20:52 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Nov 2005 17:20:46 +0100 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Nov 2005 17:20:44 +0100 Message-ID: <438DD15C.6030706@ericsson.com> Date: Wed, 30 Nov 2005 17:20:44 +0100 From: Balazs Lengyel User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phil Shafer Cc: netconf@ops.ietf.org Subject: Re: NETCONF Notifications: Consensus Points References: <200511301542.jAUFgKYE018302@idle.juniper.net> In-Reply-To: <200511301542.jAUFgKYE018302@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Nov 2005 16:20:45.0062 (UTC) FILETIME=[04152260:01C5F5CA] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I feel it is easier to separate the different fields in XML. Balazs Phil Shafer wrote: > Balazs Lengyel writes: > >>On the other hand a fault or maintenance type notification might result in further >>processing and actions so these should be kept in a structured XML format. > > > What does XML give you here that SD wouldn't? > > Thanks, > Phil -- 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 Wed Nov 30 15:33:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYe6-0002b1-F9 for netconf-archive@megatron.ietf.org; Wed, 30 Nov 2005 15:33:42 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09684 for ; Wed, 30 Nov 2005 15:32:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhYWC-000JAS-EA for netconf-data@psg.com; Wed, 30 Nov 2005 20:25:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eh6Qt-000Cvr-1v for netconf@ops.ietf.org; Tue, 29 Nov 2005 14:26:11 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jATEPrx13316; Tue, 29 Nov 2005 16:25:53 +0200 Date: Tue, 29 Nov 2005 16:25:53 +0200 (EET) From: Pekka Savola To: iesg@ietf.org cc: netconf@ops.ietf.org Subject: Re: Last Call: 'NETCONF Configuration Protocol' to Proposed Standard In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-netconf@ops.ietf.org Precedence: bulk On Wed, 23 Nov 2005, The IESG wrote: > The IESG has received a request from the Network Configuration WG to consider > the following documents: > > - 'NETCONF Configuration Protocol ' > as a Proposed Standard > - 'Using the NETCONF Configuration Protocol over Secure Shell (SSH) ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2005-12-07. I have just browsed through the main spec, because of its length. There is one potential procedural with it, as one normative reference: [5] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web", RFC 1630, June 1994. .. is Informational. The rules have been stretched now and then (e.g., when referring to hash functions defined in informational RFCs but the function is really defined by some external document), not sure if this is one similar case. Maybe a different ref would be findable on URIs? ... As a comment on section 3 of the SSH spec, In order to allow NETCONF traffic to be easily identified and filtered by firewalls and other network devices, NETCONF servers MUST default to providing access to the "netconf" SSH subsystem only when the SSH session is established using the IANA-assigned TCP port . Servers SHOULD be configurable to allow access to the netconf SSH subsystem over other ports. .. is this something that has already been implemented? Is there experience that such a restriction is practical to implement? It'd seem this would require running two different instances of sshd (with different configuration wrt subsystems) or pretty complex policies with just one process. I'm not against this approach -- I'd just like to be sure there's implementer commitment to actually do so.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- 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 Wed Nov 30 15:34:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYen-00034K-Nb for netconf-archive@megatron.ietf.org; Wed, 30 Nov 2005 15:34:25 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09746 for ; Wed, 30 Nov 2005 15:33:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhYWR-000JC3-EN for netconf-data@psg.com; Wed, 30 Nov 2005 20:25:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, MIME_HTML_ONLY,SPOOF_OURI,WHY_WAIT autolearn=no version=3.1.0 Received: from [64.76.174.188] (helo=megatron.webproject.cl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EhSqC-000JFD-8T for netconf@ops.ietf.org; Wed, 30 Nov 2005 14:21:48 +0000 Received: from nobody by megatron.webproject.cl with local (Exim 4.52) id 1EhSq2-0001hu-Tw for netconf@ops.ietf.org; Wed, 30 Nov 2005 11:21:38 -0300 To: netconf@ops.ietf.org Subject: eBay - You're a SILVER PowerSeller NOW! From: eBay Reply-To: no.reply@ebay.com MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit Message-Id: Date: Wed, 30 Nov 2005 11:21:38 -0300 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - megatron.webproject.cl X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - megatron.webproject.cl Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit
Dear eBay Member,

You've been on a super sales streak and since you've done so well, it's time to recognize you for your efforts. You are PowerSeller Silver!

Congratulations! joining the eBay Silver PowerSeller Program. Come and join us. When you join the PowerSeller program, you'll be able to receive more of the support you'll need for continued success. So, why wait? Join now!

PowerSeller icon next to your User ID in recognition of your hard work.
PowerSeller Priority Support via email webform and phone support at Silver level and above.
Exclusive offerings on the PowerSeller portal--check in frequently to see updated program benefits and special offers!
Discussion Board for you to network with other PowerSellers.
Free PowerSeller Business Templates for business cards and letterhead.

Membership to the PowerSeller program is FREE.

Again, congratulations and best wishes for your continued success!

Regards,
eBay PowerSeller Team

If you agree with this rank please Become an eBay Power Seller within 24 hours
You are receiving this communication because you are part of the PowerSeller program. This is a one time communication. There is no need to unsubscribe. eBay will not request personal data (password, credit card/bank numbers) in an email.

Copyright ? 2005 eBay Inc. All Rights Reserved.
Designated trademarks and brands are the property of their respective owners. eBay and the eBay logo are trademarks of eBay Inc.

-- 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 Wed Nov 30 16:16:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhZJZ-0007xO-2s for netconf-archive@megatron.ietf.org; Wed, 30 Nov 2005 16:16:33 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22452 for ; Wed, 30 Nov 2005 16:15:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhZDL-000N8C-UF for netconf-data@psg.com; Wed, 30 Nov 2005 21:10:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [69.31.8.124] (helo=zeke.ecotroph.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EhFAg-000L68-QF for netconf@ops.ietf.org; Tue, 29 Nov 2005 23:46:03 +0000 Received: from [192.168.0.101] ([::ffff:64.102.254.33]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Tue, 29 Nov 2005 18:45:44 -0500 id 01588032.438CE829.000036D7 Message-ID: <438CE838.1070700@thinkingcat.com> Date: Tue, 29 Nov 2005 18:46:00 -0500 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: iesg@ietf.org, netconf@ops.ietf.org Subject: Re: Last Call: 'NETCONF Configuration Protocol' to Proposed Standard References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On the first point: Pekka Savola wrote: > There is one potential procedural with it, as one normative reference: > > [5] Berners-Lee, T., "Universal Resource Identifiers in WWW: A > Unifying Syntax for the Expression of Names and Addresses of > Objects on the Network as used in the World-Wide Web", RFC 1630, > June 1994. > > .. is Informational. The rules have been stretched now and then (e.g., > when referring to hash functions defined in informational RFCs but the > function is really defined by some external document), not sure if this > is one similar case. Maybe a different ref would be findable on URIs? > Is it really really necessary to refer back to RFC1630? RFC3986 is the current URI syntax document, and has the benefit of being standards-track. Since the reference seems to be for the purpose of "defining" the URI, surely the (current) syntax document would be appropriate? Leslie. -- 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 Wed Nov 30 17:28:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhaQu-0001AW-Oa for netconf-archive@megatron.ietf.org; Wed, 30 Nov 2005 17:28:12 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08536 for ; Wed, 30 Nov 2005 17:27:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhaKY-0002pG-RM for netconf-data@psg.com; Wed, 30 Nov 2005 22:21:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EhaKY-0002p1-3E for netconf@ops.ietf.org; Wed, 30 Nov 2005 22:21:38 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jAUMLO0p011339; Wed, 30 Nov 2005 16:21:26 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 30 Nov 2005 23:21:04 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508B44F48@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Rob Enns , netconf@ops.ietf.org Subject: RE: IANA considerations update for NETCONF protocol draft Date: Wed, 30 Nov 2005 23:21:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-netconf@ops.ietf.org Precedence: bulk Inline > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Rob Enns > Sent: Wednesday, November 30, 2005 03:03 > To: netconf@ops.ietf.org > Subject: IANA considerations update for NETCONF protocol draft > > > The IANA review of the protocol draft raised some questions on how > to handle review of the spec for new capabilities. Based on those > questions > and input from Andy, here's a proposed update to the IANA > considerations > section that requests 2 different registries for NETCONF capabilities: > > - the first would be for IETF standardized capabilities, and would > require IETF consensus for new capabilities > I think we rather see IETF Standards Action. IETF consensus is a bit vague in fact. Standards Action clearly includes IETF Consensus. More below. > - the second would be for enterprise capabilities, and would be > first come first served, with a specification required > > Could the WG review this and comment? > > thanks, > Rob > > ------------------ > > 10.3. NETCONF Capability URNs > > This document requests that IANA create a registry for allocating > NETCONF capability identifiers. Allocation from the registry > requires a specification and IETF consensus (approval by the NETCONF > working group or a follow-on working group). > "approval by a WG" does not mean IETF consensus. IETF Consensus includes some for of "IETF Last Call". For stds track documents that happens automacally, and they get much better review than a "IETF Consnens Last Call for an informational or experimental. So that is why I think I prefer "Standards Action". > The initial content of the registry will be the capability URNs > defined in Section 8. Once further experience is gained with > NETCONF, this sub-namespace may be used for additional purposes. > I think last sentence can go away, because defining the registry and requiring Standards Action (or IETF consensus if that is what the WG wants) basically allow for that Netconf impact anyway. > Following the guidelines in RFC 3553 [7], IANA is requested to assign > a NETCONF sub-namespace as follows: > > Registry name: netconf > > Specification: Section 8 of this document. > > Repository: The following table. > > > +--------------------+----------------------------------------------+ > | Index | Capability Identifier | > +--------------------+----------------------------------------------+ > | :writable-running | urn:ietf:params:netconf:capability:writable- | > | | running:1.0 | .. snip .. > > Index value: The capability name. > > 10.4. NETCONF Enterprise Capability URNs > > This document requests that IANA create a registry for allocating > NETCONF capability identifiers to enterprises. Allocation from the > registry is on a First Come First Served basis, but a specification > is required in the form of Appendix C of this document. > Mmm the template in appendix C looks (to me anyway) a template to register new entries in the "standards" space, not in the vendor or enterprise space. Or am I missing something? I think we need 2 templates, no? Bert > Following the guidelines in RFC 3553 [7], IANA is requested to assign > a NETCONF sub-namespace as follows: > > Registry name: netconf-enterprise > > Specification: To be provided by the registrant. The specification > document must conform to Appendix C of this document. > > Repository: IANA is requested to store the submitted specifications > in a public location such as > http://www.iana.org/assignments/netconf/capabilities.html. > > Index value: The capability name. > > -- > 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: