From owner-netconf@ops.ietf.org Mon May 01 09:03:13 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FaY3V-0007gf-EA
	for netconf-archive@lists.ietf.org; Mon, 01 May 2006 09:03:13 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FaY3V-0002cc-03
	for netconf-archive@lists.ietf.org; Mon, 01 May 2006 09:03:13 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FaXxm-00090K-Cz
	for netconf-data@psg.com; Mon, 01 May 2006 12:57:18 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FaXxl-0008zt-0y
	for netconf@ops.ietf.org; Mon, 01 May 2006 12:57:17 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k41CvC805857
	for <netconf@ops.ietf.org>; Mon, 1 May 2006 08:57:12 -0400 (EDT)
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: manager subscription model for notifications: usage survey
Date: Mon, 1 May 2006 08:57:08 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4082BC15A@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: manager subscription model for notifications: usage survey
Thread-Index: AcZq+gSM1jjk0k/PTI27wT4rVJTLLwCI9YPg
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30


<Andy>=20
> By the way, the update, which was sent to the Internet Draft folks but

> hasn't shown up yet, does include an optional capability with=20
> different behaviour meant to handle the call-home cases. I don't=20
> expect this to be the method generally used since the normal=20
> subscription is much more predictable and reliable, but as people have

> indicated there are cases when you need to reverse roles.


There is a simple established way to do this,
without adding massive amounts of complexity.
Just define a notification target data model and use the existing RPC
operations like edit-config to fill it in.

</Andy>

That's the easy part. The complexity is around managing your
subscriptions (determining if they already exist, pushing them out to
all the devices you are managing and trying to determining if things are
running as expected), but as people have said, in some use cases the
tradeoffs for the call-home approach make sense. They don't want the
simplicity of long-lived connections that self-clean in these cases.

Sharon


>=20
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]=20
> On Behalf Of Andy Bierman
> Sent: Friday, April 28, 2006 10:21 AM
> To: Netconf (E-mail)
> Subject: manager subscription model for notifications: usage survey
>=20
>=20
> Hi,
>=20
> I am having a hard time understanding how the
> peer-to-peer manager subscribe model defined
> in the notifications draft fits with syslog and
> SNMP notifications already in use.
>=20
> Who is using this model today?
> What products work this way today?
>=20
> IMO, this is much different than the Tibco model.
> That is a publish/subscribe model with a virtual bus.
> The netconf proposal uses multiple point-to-point manager-initiated=20
> subscriptions instead.
>=20
> I think it would be wise to understand how the entire
> managed system is going to work when netconf notifications
> are added to the mix.   How will a network of 100 - 10000 devics
> behave in various common failure scenarios?
>=20
> If this subscribe-only model is not being used in a meaningful way in=20
> the real world, then I don't understand why we need to standardize it=20
> at all.
>=20
>=20
> Andy
>=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: <http://ops.ietf.org/lists/netconf/>
>=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: <http://ops.ietf.org/lists/netconf/>
>=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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 01 11:30:38 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FaaM9-0004uL-Vz
	for netconf-archive@lists.ietf.org; Mon, 01 May 2006 11:30:37 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FaaM8-0007IS-Mo
	for netconf-archive@lists.ietf.org; Mon, 01 May 2006 11:30:37 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FaaI4-000N20-61
	for netconf-data@psg.com; Mon, 01 May 2006 15:26:24 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1FaaI3-000N1o-C6
	for netconf@ops.ietf.org; Mon, 01 May 2006 15:26:23 +0000
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k41FPrU5025393
	for <netconf@ops.ietf.org>; Mon, 1 May 2006 11:25:54 -0400
content-class: urn:content-classes:message
Subject: RE: manager subscription model for notifications: usage survey
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 1 May 2006 18:23:19 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A6DFCB8@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: manager subscription model for notifications: usage survey
Thread-Index: AcZq+iESNH7yN0YoS02H1disaqPDVgCONa/A
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Andy Bierman" <ietf@andybierman.com>,
        "Sharon Chisholm" <schishol@nortel.com>
Cc: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-Whitelist: TRUE
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb



=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Friday, April 28, 2006 10:28 PM
> To: Sharon Chisholm
> Cc: Netconf (E-mail)
> Subject: Re: manager subscription model for notifications:=20
> usage survey
>=20
> Sharon Chisholm wrote:
> > hi
> >=20
> > I'm not sure which bit is tripping you up. The manager starts to=20
> > manage a network element and then subscribes for the=20
> information that=20
> > is of interest to it. If its interests change, it modifies=20
> the subscription.
> > If it no longer wishes to manage that network element (moved to=20
> > another manager for example), it cancels the subscription.=20
> If it loses=20
> > connection, it re-establishes and re-subscribes knowing that=20
> > everything got nice and cleaned up when the session went away.
>=20
>=20
> Which products work this way today?

I know very few examples in the device management world, but this method
is rather widely used in web services management.=20

Dan


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 01 13:16:49 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fac0v-000452-PH
	for netconf-archive@lists.ietf.org; Mon, 01 May 2006 13:16:49 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fac0u-0003aK-Em
	for netconf-archive@lists.ietf.org; Mon, 01 May 2006 13:16:49 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fabuq-000705-V5
	for netconf-data@psg.com; Mon, 01 May 2006 17:10:32 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fabup-0006zt-RJ
	for netconf@ops.ietf.org; Mon, 01 May 2006 17:10:32 +0000
Received: from mail.networksolutionsemail.com (ns-omr2.mgt.hosting.dc2.netsol.com [10.49.6.65])
	by ns-omrbm2.netsolmail.com (8.13.6/8.13.6) with SMTP id k41HAUWf024674
	for <netconf@ops.ietf.org>; Mon, 1 May 2006 13:10:30 -0400
Received: (qmail 12102 invoked by uid 78); 1 May 2006 17:10:30 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 1 May 2006 17:10:30 -0000
Message-ID: <445640FF.2010705@andybierman.com>
Date: Mon, 01 May 2006 10:10:23 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
CC: Sharon Chisholm <schishol@nortel.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: manager subscription model for notifications: usage survey
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0A6DFCB8@is0004avexu1.global.avaya.com>
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2F0A6DFCB8@is0004avexu1.global.avaya.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d

Romascanu, Dan (Dan) wrote:
> 
>  
>  
> 
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org 
>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
>> Sent: Friday, April 28, 2006 10:28 PM
>> To: Sharon Chisholm
>> Cc: Netconf (E-mail)
>> Subject: Re: manager subscription model for notifications: 
>> usage survey
>>
>> Sharon Chisholm wrote:
>>> hi
>>>
>>> I'm not sure which bit is tripping you up. The manager starts to 
>>> manage a network element and then subscribes for the 
>> information that 
>>> is of interest to it. If its interests change, it modifies 
>> the subscription.
>>> If it no longer wishes to manage that network element (moved to 
>>> another manager for example), it cancels the subscription. 
>> If it loses 
>>> connection, it re-establishes and re-subscribes knowing that 
>>> everything got nice and cleaned up when the session went away.
>>
>> Which products work this way today?
> 
> I know very few examples in the device management world, but this method
> is rather widely used in web services management. 


I'm trying to understand how the manager subscription model
would fit in with existing network management systems which
use one or more notification listeners, that are configured
(hard-wired or some sort of discovery procedure) on each
notification generator.

It seems to me that the subscription-based complex filtering
is a service that a notification receiver application normally
provides to other NMS applications.  I don't see the dedicated
listener model ever going away, so this manager-subscribe feature
is at best a convenience for NMS applications to move the
notification subscription service from one NMS workstation
to every embedded agent.

IMO, this doesn't make engineering sense, because the
cost of development and deployment is so much higher for
embedded systems than workstations.  (That's probably
why NE vendors don't offer this feature today.)



> 
> Dan


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: <http://ops.ietf.org/lists/netconf/>
> 
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 01 13:31:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FacFU-0007FH-1V
	for netconf-archive@lists.ietf.org; Mon, 01 May 2006 13:31:52 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FacFR-0004Fe-Ny
	for netconf-archive@lists.ietf.org; Mon, 01 May 2006 13:31:52 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fac99-0008LO-9b
	for netconf-data@psg.com; Mon, 01 May 2006 17:25:19 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1Fac98-0008L6-IW
	for netconf@ops.ietf.org; Mon, 01 May 2006 17:25:18 +0000
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k41HN5Qt026823
	for <netconf@ops.ietf.org>; Mon, 1 May 2006 13:24:47 -0400
content-class: urn:content-classes:message
Subject: RE: manager subscription model for notifications: usage survey
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 1 May 2006 20:23:33 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A6DFD11@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: manager subscription model for notifications: usage survey
Thread-Index: AcZtQii6fW0UZqVKQDO/M6Ygo18XvQAAa9bg
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Andy Bierman" <ietf@andybierman.com>
Cc: "Sharon Chisholm" <schishol@nortel.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-Whitelist: TRUE
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3



=20
=20

> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com]=20

>=20
> IMO, this doesn't make engineering sense, because the cost of=20
> development and deployment is so much higher for embedded=20
> systems than workstations.  (That's probably why NE vendors=20
> don't offer this feature today.)
>=20
>=20

Is it really much more complex to implement than the SNMP-TARGET-MIB and
SNMP-NOTIFICATION-MIB?=20

Dan


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 01 14:31:55 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FadBb-000361-5K
	for netconf-archive@lists.ietf.org; Mon, 01 May 2006 14:31:55 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FadBZ-0006N0-Rs
	for netconf-archive@lists.ietf.org; Mon, 01 May 2006 14:31:55 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fad6j-000E2g-Pw
	for netconf-data@psg.com; Mon, 01 May 2006 18:26:53 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fad6g-000E2N-Mk
	for netconf@ops.ietf.org; Mon, 01 May 2006 18:26:53 +0000
Received: from mail.networksolutionsemail.com (ns-omr5.mgt.hosting.dc2.netsol.com [10.49.6.68])
	by ns-omrbm5.netsolmail.com (8.13.6/8.13.6) with SMTP id k41IQnDc022578
	for <netconf@ops.ietf.org>; Mon, 1 May 2006 14:26:50 -0400
Received: (qmail 4609 invoked by uid 78); 1 May 2006 18:26:49 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.68 with SMTP; 1 May 2006 18:26:49 -0000
Message-ID: <445652E4.5080707@andybierman.com>
Date: Mon, 01 May 2006 11:26:44 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
CC: Sharon Chisholm <schishol@nortel.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: manager subscription model for notifications: usage survey
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0A6DFD11@is0004avexu1.global.avaya.com>
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2F0A6DFD11@is0004avexu1.global.avaya.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336

Romascanu, Dan (Dan) wrote:
> 
>  
>  
> 
>> -----Original Message-----
>> From: Andy Bierman [mailto:ietf@andybierman.com] 
> 
>> IMO, this doesn't make engineering sense, because the cost of 
>> development and deployment is so much higher for embedded 
>> systems than workstations.  (That's probably why NE vendors 
>> don't offer this feature today.)
>>
>>
> 
> Is it really much more complex to implement than the SNMP-TARGET-MIB and
> SNMP-NOTIFICATION-MIB? 

Maybe about the same, but who is using the full capability
of these MIBs today?  Some complexity is due to the lack
of nested data structures in SMI, which is not a problem in XML.
I don't think the netconf configuration of a notification
generator application would need to be as complex.

My biggest concern is one of actual deployment.
If NE vendors are not inclined to offer this feature now,
then why is it all of a sudden going to become a great
idea when it shows up in a netconf RFC?

I'm not saying this is one of those "must-have features nobody
ever heard of" that Phil mentioned.  I'm saying if this was
really useful, then vendors would already be doing it in some
form, in some products.  Some WG members have told me "well,
the vendors don't know what they're doing.  We need do what's
right anyway."  IMO, this is the kind of thinking that got us into
a disconnect with the operator community in the first place.


> 
> Dan

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 01 15:18:03 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FaduF-0000z2-Et
	for netconf-archive@lists.ietf.org; Mon, 01 May 2006 15:18:03 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fadu7-0007wv-4T
	for netconf-archive@lists.ietf.org; Mon, 01 May 2006 15:18:03 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fadp1-000IvQ-BC
	for netconf-data@psg.com; Mon, 01 May 2006 19:12:39 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1Fadoz-000IvF-KX
	for netconf@ops.ietf.org; Mon, 01 May 2006 19:12:37 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id A1CDC55F48;
	Mon,  1 May 2006 21:12:36 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 13666-04; Mon,  1 May 2006 21:12:34 +0200 (CEST)
Received: from boskop.local (unknown [10.222.1.1])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id C8BD155E1C;
	Mon,  1 May 2006 21:12:34 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id 41DCF6C41D1; Mon,  1 May 2006 21:12:33 +0200 (CEST)
Date: Mon, 1 May 2006 21:12:32 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Cc: Andy Bierman <ietf@andybierman.com>,
	Sharon Chisholm <schishol@nortel.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: manager subscription model for notifications: usage survey
Message-ID: <20060501191232.GB26801@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>,
	Andy Bierman <ietf@andybierman.com>,
	Sharon Chisholm <schishol@nortel.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0A6DFD11@is0004avexu1.global.avaya.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2F0A6DFD11@is0004avexu1.global.avaya.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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4

On Mon, May 01, 2006 at 08:23:33PM +0300, Romascanu, Dan (Dan) wrote:
 
> Is it really much more complex to implement than the SNMP-TARGET-MIB and
> SNMP-NOTIFICATION-MIB? 

You are right that the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB
basically allow subscriptions (and they are pretty complicated to use
with all the features that went in). These MIBs, however, have two
problems that are important if you want to use them:

a) Notification targets can't be bound to a "session" nor are there any
   timers which cause targets to expire if the timer is not refreshed.
   Hence, garbage collection of dead dynamic subscriptions is a mess.
   This is an engineering problem which could be fixed easily by
   adding the missing capability to the standards.

b) Most default installations are simply read-only and it typically
   requires to use the CLI to add a subscription. Given the lack of
   standards in this space, you can't really write interoperable code
   that actually works in operational networks. This is mainly a
   deployment problem and could be solved by agreeing on common access
   control setups that actually allow more useful work to happen (but
   again will take a long time to become effective).

By introducing a subscription mechanism which uses additional protocol
verbs rather than a writable data model, you kind of automatically
make it much more likely that neither a) nor b) becomes a problem.

Subscription operations make management applications that like to
subscribe to notifications easier to write and I believe this is a
feature and not a bug.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 02 03:15:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fap6N-00062Z-0O
	for netconf-archive@lists.ietf.org; Tue, 02 May 2006 03:15:19 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fap6L-0003T0-CN
	for netconf-archive@lists.ietf.org; Tue, 02 May 2006 03:15:18 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fap0u-000B6z-Gv
	for netconf-data@psg.com; Tue, 02 May 2006 07:09:40 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1Fap0s-000B6b-SK
	for netconf@ops.ietf.org; Tue, 02 May 2006 07:09:39 +0000
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AA5AC4F0029
	for <netconf@ops.ietf.org>; Tue,  2 May 2006 09:09:35 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 2 May 2006 09:09:35 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 2 May 2006 09:09:35 +0200
Message-ID: <445705B1.2090006@ericsson.com>
Date: Tue, 02 May 2006 09:09:37 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: manager subscription model for notifications: usage survey
References: <445224D1.4080807@andybierman.com>
In-Reply-To: <445224D1.4080807@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 May 2006 07:09:35.0394 (UTC) FILETIME=[5E3A0020:01C66DB7]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007

Andy mentions 100-1000 devices. In Ericsson we have systems supervising up to 30000 
devices. So we should aim somewhat higher with scalability. (Today these use other 
protocols, but they are a candidate for Netconf.)
Balazs

Andy Bierman wrote:
> Hi,
> 
> I am having a hard time understanding how the
> peer-to-peer manager subscribe model defined
> in the notifications draft fits with syslog and
> SNMP notifications already in use.
> 
> 
> I think it would be wise to understand how the entire
> managed system is going to work when netconf notifications
> are added to the mix.   How will a network of 100 - 10000 devics
> behave in various common failure scenarios?
> 

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 02 03:15:25 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fap6T-0006TG-41
	for netconf-archive@lists.ietf.org; Tue, 02 May 2006 03:15:25 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fap6Q-0003T4-IH
	for netconf-archive@lists.ietf.org; Tue, 02 May 2006 03:15:25 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fap3Y-000BP7-1F
	for netconf-data@psg.com; Tue, 02 May 2006 07:12:24 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1Fap3W-000BOr-NR
	for netconf@ops.ietf.org; Tue, 02 May 2006 07:12:22 +0000
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 63AA34F0006
	for <netconf@ops.ietf.org>; Tue,  2 May 2006 09:12:17 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 2 May 2006 09:12:13 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 2 May 2006 09:12:13 +0200
Message-ID: <4457064F.1050304@ericsson.com>
Date: Tue, 02 May 2006 09:12:15 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: manager subscription model for notifications: usage survey
References: <713043CE8B8E1348AF3C546DBE02C1B4082BBB6C@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4082BBB6C@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 May 2006 07:12:13.0203 (UTC) FILETIME=[BC49BE30:01C66DB7]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2

Hi
Could you please give some examples when does this happen that "the interest of the 
manager changes".
Balazs

Sharon Chisholm wrote:
> The manager starts to manage
> a network element and then subscribes for the information that is of
> interest to it. If its interests change, it modifies the subscription.

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 02 10:25:48 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Favoy-0005IG-30
	for netconf-archive@lists.ietf.org; Tue, 02 May 2006 10:25:48 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Favox-0005yY-Pf
	for netconf-archive@lists.ietf.org; Tue, 02 May 2006 10:25:48 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Favfw-0004iu-M3
	for netconf-data@psg.com; Tue, 02 May 2006 14:16:28 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [192.11.226.163] (helo=hoemail2.lucent.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <bwijnen@lucent.com>)
	id 1Favfv-0004ig-SD
	for netconf@ops.ietf.org; Tue, 02 May 2006 14:16:28 +0000
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k42EGO3J005730;
	Tue, 2 May 2006 09:16:25 -0500 (CDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <JHKT58LQ>; Tue, 2 May 2006 16:16:23 +0200
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509EAE04E@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Andy Bierman <ietf@andybierman.com>,
        "Netconf (E-mail)"
	 <netconf@ops.ietf.org>
Subject: RE: [Fwd: I-D ACTION:draft-ietf-netconf-notification-01.txt]
Date: Tue, 2 May 2006 16:16:13 +0200 
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15

I did a first skim over this document.

Here is an initial set of admin/consitency comments (i.e.
no real technical review comments yet):

- This document should align itself with the approved NetConf
  documents and use the same terminology. For example:
  - figure 1: change "Application Protocol" into "Transport Protocol"
  - sect 5 title should be: Mapping to Transport Protocols
    Best to check the whole doc for "application protocol" and
    change accordingly.
- consistency within document, for example:
  - sect 5.1 page 25
          <event-class><configuration/><audit/></event-classes>
    is it event-class or event-classes?
    or is it eventClass as per the following on page 27:
          <eventClass><configuration/><audit/></eventClass>
  - sect 3.4.1 seems to contradict the description under "Named Profile"
    in sections 2.1.1 and 2.3.1
  - I see
      <capability>
        urn:ietf:params:xml:ns:netconf:notification:1.0
      </capability>
    and
        xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0
    and
       <rpc message-id="101"
        xmlns="urn:ietf:params:xml:ns:netconf:event:1.0">
    So there seems to be inconsistency here?

Bert
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Andy Bierman
> Sent: Saturday, April 29, 2006 03:15
> To: Netconf (E-mail)
> Subject: [Fwd: I-D ACTION:draft-ietf-netconf-notification-01.txt]
> 
> 
> Hi,
> 
> A new version of the NETCONF Notifications draft is out.
> 
> I would really like to see some detailed reviews of
> this draft.  If you want notifications in netconf,
> then you need to read this draft and make sure this
> is exactly how you want notifications done.  If it isn't,
> or text is unclear or incorrect, then tell the WG.
> 
> If you don't want notifications in netconf, then
> that would be good to know too.  Silence means
> lack of interest, not acceptance.
> 
> 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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 02 11:13:45 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FawZN-0003Ao-0H
	for netconf-archive@lists.ietf.org; Tue, 02 May 2006 11:13:45 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FawZI-0007xT-I0
	for netconf-archive@lists.ietf.org; Tue, 02 May 2006 11:13:44 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FawOI-0009dM-Gg
	for netconf-data@psg.com; Tue, 02 May 2006 15:02:18 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1
Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <htrevino@cisco.com>)
	id 1FawOH-0009dB-OL
	for netconf@ops.ietf.org; Tue, 02 May 2006 15:02:17 +0000
Received: from sj-core-5.cisco.com ([171.71.177.238])
  by sj-iport-1.cisco.com with ESMTP; 02 May 2006 08:02:17 -0700
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 k42F2HRT003036;
	Tue, 2 May 2006 08:02:17 -0700 (PDT)
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, 2 May 2006 08:02:17 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Fwd: I-D ACTION:draft-ietf-netconf-notification-01.txt]
Date: Tue, 2 May 2006 08:02:15 -0700
Message-ID: <6E21698722408147BEA594E073E2B0AB01CA02FD@xmb-sjc-223.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Fwd: I-D ACTION:draft-ietf-netconf-notification-01.txt]
Thread-Index: AcZt83G6m5tx4N1bTPW8PLXTUS7mDwABd/IA
From: "Hector Trevino \(htrevino\)" <htrevino@cisco.com>
To: "Wijnen, Bert \(Bert\)" <bwijnen@lucent.com>,
        "Andy Bierman" <ietf@andybierman.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 02 May 2006 15:02:17.0142 (UTC) FILETIME=[67254D60:01C66DF9]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8


Thanks, we'll make the updates.
Hector
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Wijnen, Bert (Bert)
> Sent: Tuesday, May 02, 2006 8:16 AM
> To: Andy Bierman; Netconf (E-mail)
> Subject: RE: [Fwd: I-D ACTION:draft-ietf-netconf-notification-01.txt]
>=20
> I did a first skim over this document.
>=20
> Here is an initial set of admin/consitency comments (i.e.
> no real technical review comments yet):
>=20
> - This document should align itself with the approved NetConf
>   documents and use the same terminology. For example:
>   - figure 1: change "Application Protocol" into "Transport Protocol"
>   - sect 5 title should be: Mapping to Transport Protocols
>     Best to check the whole doc for "application protocol" and
>     change accordingly.
> - consistency within document, for example:
>   - sect 5.1 page 25
>           <event-class><configuration/><audit/></event-classes>
>     is it event-class or event-classes?
>     or is it eventClass as per the following on page 27:
>           <eventClass><configuration/><audit/></eventClass>
>   - sect 3.4.1 seems to contradict the description under=20
> "Named Profile"
>     in sections 2.1.1 and 2.3.1
>   - I see
>       <capability>
>         urn:ietf:params:xml:ns:netconf:notification:1.0
>       </capability>
>     and
>         xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0
>     and
>        <rpc message-id=3D"101"
>         xmlns=3D"urn:ietf:params:xml:ns:netconf:event:1.0">
>     So there seems to be inconsistency here?
>=20
> Bert
> > -----Original Message-----
> > From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org]On
> > Behalf Of Andy Bierman
> > Sent: Saturday, April 29, 2006 03:15
> > To: Netconf (E-mail)
> > Subject: [Fwd: I-D ACTION:draft-ietf-netconf-notification-01.txt]
> >=20
> >=20
> > Hi,
> >=20
> > A new version of the NETCONF Notifications draft is out.
> >=20
> > I would really like to see some detailed reviews of this draft.  If=20
> > you want notifications in netconf, then you need to read this draft=20
> > and make sure this is exactly how you want notifications=20
> done.  If it=20
> > isn't, or text is unclear or incorrect, then tell the WG.
> >=20
> > If you don't want notifications in netconf, then that would=20
> be good to=20
> > know too.  Silence means lack of interest, not acceptance.
> >=20
> > thanks,
> > Andy
> >=20
> >=20
>=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: <http://ops.ietf.org/lists/netconf/>
>=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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 02 13:02:53 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FayGz-0002Tc-Hy
	for netconf-archive@lists.ietf.org; Tue, 02 May 2006 13:02:53 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FayGw-0004Kx-5K
	for netconf-archive@lists.ietf.org; Tue, 02 May 2006 13:02:53 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FayDc-000MnD-F9
	for netconf-data@psg.com; Tue, 02 May 2006 16:59:24 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [209.128.82.1] (helo=shell4.bayarea.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <dperkins@dsperkins.com>)
	id 1FayDa-000Mmn-0x
	for netconf@ops.ietf.org; Tue, 02 May 2006 16:59:22 +0000
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k42GxCRF023580;
	Tue, 2 May 2006 09:59:12 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k42GxBes023571;
	Tue, 2 May 2006 09:59:11 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Tue, 2 May 2006 09:59:10 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
cc: "Romascanu, Dan (Dan)" <dromasca@avaya.com>,
        Andy Bierman <ietf@andybierman.com>,
        Sharon Chisholm <schishol@nortel.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: manager subscription model for notifications: usage survey
In-Reply-To: <20060501191232.GB26801@boskop.local>
Message-ID: <Pine.LNX.4.10.10605020956580.22181-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002

HI,

Excellent description of the problems with the current SNMPv3
notification distribution system, and why a change would
increase interoperability and usability! 

On Mon, 1 May 2006, Juergen Schoenwaelder wrote:
> On Mon, May 01, 2006 at 08:23:33PM +0300, Romascanu, Dan (Dan) wrote:
>  
> > Is it really much more complex to implement than the SNMP-TARGET-MIB and
> > SNMP-NOTIFICATION-MIB? 
> 
> You are right that the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB
> basically allow subscriptions (and they are pretty complicated to use
> with all the features that went in). These MIBs, however, have two
> problems that are important if you want to use them:
> 
> a) Notification targets can't be bound to a "session" nor are there any
>    timers which cause targets to expire if the timer is not refreshed.
>    Hence, garbage collection of dead dynamic subscriptions is a mess.
>    This is an engineering problem which could be fixed easily by
>    adding the missing capability to the standards.
> 
> b) Most default installations are simply read-only and it typically
>    requires to use the CLI to add a subscription. Given the lack of
>    standards in this space, you can't really write interoperable code
>    that actually works in operational networks. This is mainly a
>    deployment problem and could be solved by agreeing on common access
>    control setups that actually allow more useful work to happen (but
>    again will take a long time to become effective).
> 
> By introducing a subscription mechanism which uses additional protocol
> verbs rather than a writable data model, you kind of automatically
> make it much more likely that neither a) nor b) becomes a problem.
> 
> Subscription operations make management applications that like to
> subscribe to notifications easier to write and I believe this is a
> feature and not a bug.
> 
> /js
> 
Regards,
/david t. perkins


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 02 13:47:36 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FayyG-0007m5-OJ
	for netconf-archive@lists.ietf.org; Tue, 02 May 2006 13:47:36 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FayyG-00079K-9C
	for netconf-archive@lists.ietf.org; Tue, 02 May 2006 13:47:36 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FayqM-000PbP-ND
	for netconf-data@psg.com; Tue, 02 May 2006 17:39:26 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FayqL-000PbA-FL
	for netconf@ops.ietf.org; Tue, 02 May 2006 17:39:25 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.hosting.dc2.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k42Hd7Gb028074
	for <netconf@ops.ietf.org>; Tue, 2 May 2006 13:39:14 -0400
Received: (qmail 1797 invoked by uid 78); 2 May 2006 17:38:45 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 2 May 2006 17:38:45 -0000
Message-ID: <4457991E.1010901@andybierman.com>
Date: Tue, 02 May 2006 10:38:38 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: comments on draft-ietf-netconf-notification-01.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee

Hi,

This is not a full review.
I'm still waiting for some WG members to do that.

-----------------------

General comments:

  - The draft still lacks any discussion of why we need this
    document, what role it plays in the overall netconf architecture.

  - The use of special RPCs, named profiles, and a read-only data model
    goes against the core concept of netconf -- use the standard operations
    to manipulate standard read-write data models.  The convoluted manner
    in which a traditional notification generation application would be
    realized would win a Rube Goldberg Machine Contest.

    I strongly object to this design approach.

  - multiple subscriptions per session

    I strongly object to this feature.
    There is no rationale given for it.
    Netconf has a single-user session model.
    The NMS can use modify-subscription instead of creating multiple
    subscriptions.  The NMS, not the agent, should provide this
    additional, programmable classification service.  The complexity
    added to the document to move this classification service to
    the agent is unwarranted, and the feature is totally redundant.

  - Event classes

    I strongly object to this document defining the mandatory set of
    event classifications.  This document should simply define a
    field that contains a constrained string, which can be used for
    filtering purposes.  The list still contains enumerations such as
    'metrics' and 'heartbeat' which were supposed to be removed.
    There are under-specified semantics and requirements for many
    of these classifications.

    The actual set of standard events is a modeling problem, and is
    out of scope in this WG.

--------------------------------------

page 4:

   "discusses implications for the mapping of application protocols"


Is this document doing to define the normative procedures
for supporting notifications on each transport?  I think
this would be better than generating 4 RFCs instead of 1,
but the WG needs to decide where the normative transport-specific
text will be located.

----------------

page 4:

NETCONF[NETCONF] --> NETCONF [NETCONF-PROTO]

---------------

sec. 2:

There are no examples shown for each RPC operation.
There should be examples here instead of spread out
in the end of the document.

----------------

page 6:

<create-subscription>

"This command .."

Wrong terminology.
Use RPC method or operation.

-----------------

page 6:

<named-profile>

This is still an opaque, under-specified proprietary hack.
There should be a read-write standard data model with
standard parameters -- and nothing else.

I strongly object to this parameter.
If vendors want to ignore the standard parameters
and use their own instead, then XML already allows them to
do that -- we should not help them hack around the standard
within the standard itself.

----------------


<notification>

Positive Response: no response, etc.

This only applies to RPCs, so it can be removed here.

------------------

notification examples in section 5:

It should be made clear they are only examples
and are not normative.  The examples need to be explained
as well.

These examples are unrealistic.
I don't think it's proper for the agent to return a copy of all
the config that actually changed in a 'config-change' notification.
This could be really verbose, introduce access control problems,
and it's not really needed anyway, if the NMS is designed correctly.

------------------

schema comments

- an unspecified access control model is thrown in
   with these 'minAccess' and 'maxAccess' <appinfo> additions.
   There is no agreement in the WG on these XSD extensions,
   or understanding of the functional requirements.

-----------------

filter example comments

Sec 6.2 introduces additional 'severity=foo' filtering syntax
without really explaining it.

Not sure what this <neb> element is in the example.

<netconf:filter> is broken XML -- there is no 'netconf' prefix
or an xmlns declared in the example.


------------------

section 7.1.1.1 session lifecycle

The WG did not discuss or approve any such feature.
This watchdog-timer design doesn't work in a mixed-mode
session very well.  The netconf agent never abruptly
terminates a live session.  The lack of architecture discussion
in this document jumps out in this section.  There is no
mention of the agent constantly starting and tearing down sessions
anywhere else.

This section needs to be removed.

------------------

Appendix A: Design Alternatives

A.1 Suspend and Resume

This section introduces even more complexity with new
<suspend-subscription> and <resume-subscription> RPCs.

I strongly object to all of these specialized RPCs.
If we have a proper read-write data model, the standard
operations such as <edit-config> provide all the
configuration manipulation features we need.

The agent already has code to implement <edit-config>.
All of these special RPCs which are used to avoid <edit-config>
add extra code and complexity to the agent.

--------------------

A.2 Lifecycle

This section is incorrect and needs to be removed.
The NETCONF-PROT document already mandates certain
non-volatile storage requirements.  This section
contradicts that normative text.

---------------------

Appendix B: Syslog within NETCONF events

events --> notifications

This section does dot clearly define how to encode the
XML PDU.  This should be a normative section (and fully
specified) or removed from the document.

Notification forwarding options needs to be agreed upon
by the WG, and fully explained in a detailed architecture
section.

There is no proxy in netconf, and I aim to keep it that way.

---------------------

Appendix C: Example Configuration Notifications

This section needs to be removed.
If the WG can agree of fully-specified standard notifications,
then they will included in normative text.

-------------------








--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 03 06:06:26 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbEFW-0002wj-9K
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 06:06:26 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbEFU-00082B-VG
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 06:06:26 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbE9I-0000YL-D7
	for netconf-data@psg.com; Wed, 03 May 2006 10:00:00 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [192.11.226.163] (helo=hoemail2.lucent.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <bwijnen@lucent.com>)
	id 1FbE9H-0000Y5-3S
	for netconf@ops.ietf.org; Wed, 03 May 2006 09:59:59 +0000
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k439xujB025569;
	Wed, 3 May 2006 04:59:57 -0500 (CDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <JHKT6L6D>; Wed, 3 May 2006 11:59:55 +0200
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509EAE2D3@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Andy Bierman <ietf@andybierman.com>,
        "Netconf (E-mail)"
	 <netconf@ops.ietf.org>
Subject: RE: comments on draft-ietf-netconf-notification-01.txt
Date: Wed, 3 May 2006 11:59:55 +0200 
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906

W.r.t.
> General comments:
> 
>   - The draft still lacks any discussion of why we need this
>     document, what role it plays in the overall netconf architecture.
> 

I wonder where we are with the discussion of that topic of why we
need notifications and if we need them, what exactly we need them for.
Remember that Juergen was/is keeping track at:

  http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications

It is (iirc) just a list of what people have posted, and it does NOT 
represent WG consensus as to what the motivations and requirements are.
Should we try to see if we (as a WG) can get to consensus on that?

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 03 07:22:42 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbFRK-0004Dk-Cy
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 07:22:42 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbFRI-0002Yh-2a
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 07:22:42 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbFNO-0004dB-Sl
	for netconf-data@psg.com; Wed, 03 May 2006 11:18:38 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FbFNN-0004cw-R4
	for netconf@ops.ietf.org; Wed, 03 May 2006 11:18:38 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k43BIX018635
	for <netconf@ops.ietf.org>; Wed, 3 May 2006 07:18:33 -0400 (EDT)
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: manager subscription model for notifications: usage survey
Date: Wed, 3 May 2006 07:18:30 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4083DCBE8@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: manager subscription model for notifications: usage survey
Thread-Index: AcZtuE+s7gcxISdhQj+KYlCHyiLwRQA6q6MA
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d

hi

One example would be that in order to debug a particular problem it
wants to start receiving notifications that before were considered not
sufficiently interesting.  Or alternatively, if the subscribing to a
particular class of events proves to be more noisy then expected, the
manager may wish to stop subscribing to this class of events.

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Balazs Lengyel
Sent: Tuesday, May 02, 2006 3:12 AM
To: Netconf (E-mail)
Subject: Re: manager subscription model for notifications: usage survey


Hi
Could you please give some examples when does this happen that "the
interest of the=20
manager changes".
Balazs

Sharon Chisholm wrote:
> The manager starts to manage
> a network element and then subscribes for the information that is of=20
> interest to it. If its interests change, it modifies the subscription.

--
to unsubscribe send a message to netconf-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 03 08:07:56 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbG96-0005FJ-15
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 08:07:56 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbG94-0004qc-DK
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 08:07:56 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbG58-000785-3e
	for netconf-data@psg.com; Wed, 03 May 2006 12:03:50 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FbG56-00077s-Ot
	for netconf@ops.ietf.org; Wed, 03 May 2006 12:03:48 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k43C3i029347
	for <netconf@ops.ietf.org>; Wed, 3 May 2006 08:03:44 -0400 (EDT)
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: comments on draft-ietf-netconf-notification-01.txt
Date: Wed, 3 May 2006 08:03:41 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4083DCC34@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: comments on draft-ietf-netconf-notification-01.txt
Thread-Index: AcZuENvB/jHxIgucSjuSjqWZ/zWH5wAkobWQ
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35

hi

Thanks for the review ....

<Andy>
  - The use of special RPCs, named profiles, and a read-only data model
    goes against the core concept of netconf -- use the standard
operations
    to manipulate standard read-write data models.  The convoluted
manner
    in which a traditional notification generation application would be
    realized would win a Rube Goldberg Machine Contest.
</Andy>

The subscription command is easier then other 'traditional' models for
the person doing the subscribing. We have modified the named profiles to
be a persistent set of information related to subscriptions for those
who are more interested in that approach. I'm hoping by 'traditional
notification generator' that you don't mean you wish to duplicate an
SNMP notification generator in Netconf. That model is one that we should
learn from and move on.


<Andy strongly objecting to multiple subscriptions per session>

It seems more work to me to preclude it then allow it. There are
advantages to being able to organize two different sets of filters into
two different subscriptions.=20

<Andy>
  - Event classes

    I strongly object to this document defining the mandatory set of
    event classifications.  This document should simply define a
    field that contains a constrained string, which can be used for
    filtering purposes.  The list still contains enumerations such as
    'metrics' and 'heartbeat' which were supposed to be removed.
    There are under-specified semantics and requirements for many
    of these classifications.

    The actual set of standard events is a modeling problem, and is
    out of scope in this WG.

</Andy>

I strong support the inclusion of event classes in the document. I
thought we had agreed we had consensus that this was useful and should
be included? It lets the consumer of the message know what the content
will be and enables the receiver to route the notification to the
appropriate consumers. It is very useful and comparable in data model
bleed to candidate and running configuration in the base protocol work.

The idea here it to only specify the class and defer the content of the
message to the datamodel.=20

We still have the open discussion on what the initial set of values is
and how they will be extended. There was discussion about a more
URI-based extension instead of an enumerated list, but as was discussed,
there are some serious disadvantages to this approach. This is similar
to the enumerated list versus rowPointer debate we always had in SNMP.
One-stop-shopping of enumerated lists provide much more ease of use and
predictability then open-ended where-can-I-find-all-the-values things
like URIs. URIs are good for big things like protocol operations and
Schema namespace, but not for everything. Either way, putting the list
in IANA seems reasonable.
--------------------------------------

<Andy>
page 4:

   "discusses implications for the mapping of application protocols"


Is this document doing to define the normative procedures
for supporting notifications on each transport?  I think
this would be better than generating 4 RFCs instead of 1,
but the WG needs to decide where the normative transport-specific text
will be located.
</Andy>

The text is more there because it needs to be somewhere. I like the idea
of updating the existing three transport documents (once they get
published) then creating separate ones.=20


<Andy>
----------------

page 4:

NETCONF[NETCONF] --> NETCONF [NETCONF-PROTO]

---------------

sec. 2:

There are no examples shown for each RPC operation.
There should be examples here instead of spread out
in the end of the document.

----------------

page 6:

<create-subscription>

"This command .."

Wrong terminology.
Use RPC method or operation.

-----------------
</Andy>

ok

<Andy>

page 6:

<named-profile>

This is still an opaque, under-specified proprietary hack. There should
be a read-write standard data model with standard parameters -- and
nothing else.

I strongly object to this parameter.
If vendors want to ignore the standard parameters
and use their own instead, then XML already allows them to
do that -- we should not help them hack around the standard within the
standard itself.

</Andy>

Sorry? In the latest specification, the data model associated with the
named profile is clearly defined. It's even read-write. What exactly is
it you are looking for?

----------------

<Andy>

<notification>

Positive Response: no response, etc.

This only applies to RPCs, so it can be removed here.
</Andy>

I disagree. I think it should be explicitly stated that there is no
response. First of all, because we could have made these acknowledged
events built on RPCs and second of all I still say the average reader
thinks about the Netconf operations rather then the RPC analogy we have
chosen to express them with.=20

------------------

<Andy>
notification examples in section 5:

It should be made clear they are only examples
and are not normative.  The examples need to be explained
as well.

These examples are unrealistic.
I don't think it's proper for the agent to return a copy of all the
config that actually changed in a 'config-change' notification. This
could be really verbose, introduce access control problems, and it's not
really needed anyway, if the NMS is designed correctly.
</Andy>

We have added this disclaimer to other examples, but not those in
section 5. We can do that. We have identified two types of configuration
change events. The first provides more of a summary of changes in some
useful format (new interface up or something) and the second would
actually mirror the configuration command sent. The latter is necessary
for security audit logs.=20

Notifications always have access control issues. People need to have
permission to see the data that is in the notifications.

------------------

<Andy>
schema comments

- an unspecified access control model is thrown in
   with these 'minAccess' and 'maxAccess' <appinfo> additions.
   There is no agreement in the WG on these XSD extensions,
   or understanding of the functional requirements.

</Andy>

Yeah, that is a bit of a problem. We need this mechanism, but we don't
have a standard one yet. So, we are using the one defined in
http://www.ietf.org/internet-drafts/draft-chisholm-netconf-model-05.txt


-----------------
<Andy>

filter example comments

Sec 6.2 introduces additional 'severity=3Dfoo' filtering syntax without
really explaining it.

Not sure what this <neb> element is in the example.

<netconf:filter> is broken XML -- there is no 'netconf' prefix or an
xmlns declared in the example.
</Andy>

Hmmm. Need to look into these.=20

------------------

<Andy>
section 7.1.1.1 session lifecycle

The WG did not discuss or approve any such feature.
This watchdog-timer design doesn't work in a mixed-mode
session very well.  The netconf agent never abruptly
terminates a live session.  The lack of architecture discussion in this
document jumps out in this section.  There is no mention of the agent
constantly starting and tearing down sessions anywhere else.

This section needs to be removed.

</Andy>

Just the session lifecycle or the CallHome thing? Our understanding was
that there was consensus to look at how to address the callHome thing
and the session lifecycle is discussion related to that feature. If
there is no consensus for the callHome thing, we can move it back to the
design alternative appendix


--------------------

A.2 Lifecycle

This section is incorrect and needs to be removed.
The NETCONF-PROT document already mandates certain
non-volatile storage requirements.  This section
contradicts that normative text.

</Andy>

We'll have to look into it. I suspect this is a misinterpretation of
what is written rather then this design alternative was proposing
something in violation of what is the in the PROTO draft.

---------------------

<Andy>
Appendix B: Syslog within NETCONF events

events --> notifications

This section does dot clearly define how to encode the
XML PDU.  This should be a normative section (and fully
specified) or removed from the document.

Notification forwarding options needs to be agreed upon
by the WG, and fully explained in a detailed architecture section.

There is no proxy in netconf, and I aim to keep it that way.
</Andy>

We were not sure if there was consensus for this feature to be moved to
the main body of the document. We did add the new event class to support
the tunnelling though.

We don't specify how to encode any of the other event content. I don't
know if we should be doing it for this one case.

---------------------
<Andy>

Appendix C: Example Configuration Notifications

This section needs to be removed.
If the WG can agree of fully-specified standard notifications, then they
will included in normative text.

</Andy>

While we did delete the sections that provided examples for
non-configuration notifications, we were hesitant to delete this section
because we actually referred to it during discussions last month. It
might be useful to keep around for a bit longer.


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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 03 11:47:24 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbJZU-0005LY-26
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 11:47:24 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbIXs-00031u-2s
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 10:41:40 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FbIGo-0005ld-4G
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 10:24:06 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbI88-000ETH-MU
	for netconf-data@psg.com; Wed, 03 May 2006 14:15:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FbI86-000ESV-GB
	for netconf@ops.ietf.org; Wed, 03 May 2006 14:15:03 +0000
Received: from mail.networksolutionsemail.com (ns-omr2.mgt.hosting.dc2.netsol.com [10.49.6.65])
	by ns-omrbm2.netsolmail.com (8.13.6/8.13.6) with SMTP id k43EF0cv010609
	for <netconf@ops.ietf.org>; Wed, 3 May 2006 10:15:01 -0400
Received: (qmail 31563 invoked by uid 78); 3 May 2006 14:07:56 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 3 May 2006 14:07:56 -0000
Message-ID: <4458B933.8090102@andybierman.com>
Date: Wed, 03 May 2006 07:07:47 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: comments on draft-ietf-netconf-notification-01.txt
References: <713043CE8B8E1348AF3C546DBE02C1B4083DCC34@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4083DCC34@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
X-Spam-Score: -1.0 (-)
X-Scan-Signature: efc5d1db3729b4b7031f1bb5f5a30ae3

Sharon Chisholm wrote:
> hi
> 
> Thanks for the review ....
> 
> <Andy>
>   - The use of special RPCs, named profiles, and a read-only data model
>     goes against the core concept of netconf -- use the standard
> operations
>     to manipulate standard read-write data models.  The convoluted
> manner
>     in which a traditional notification generation application would be
>     realized would win a Rube Goldberg Machine Contest.
> </Andy>
> 
> The subscription command is easier then other 'traditional' models for
> the person doing the subscribing. We have modified the named profiles to
> be a persistent set of information related to subscriptions for those
> who are more interested in that approach. I'm hoping by 'traditional
> notification generator' that you don't mean you wish to duplicate an
> SNMP notification generator in Netconf. That model is one that we should
> learn from and move on.
> 
> 
> <Andy strongly objecting to multiple subscriptions per session>
> 
> It seems more work to me to preclude it then allow it. There are
> advantages to being able to organize two different sets of filters into
> two different subscriptions. 
> 
> <Andy>
>   - Event classes
> 
>     I strongly object to this document defining the mandatory set of
>     event classifications.  This document should simply define a
>     field that contains a constrained string, which can be used for
>     filtering purposes.  The list still contains enumerations such as
>     'metrics' and 'heartbeat' which were supposed to be removed.
>     There are under-specified semantics and requirements for many
>     of these classifications.
> 
>     The actual set of standard events is a modeling problem, and is
>     out of scope in this WG.
> 
> </Andy>
> 
> I strong support the inclusion of event classes in the document. I
> thought we had agreed we had consensus that this was useful and should
> be included? It lets the consumer of the message know what the content
> will be and enables the receiver to route the notification to the
> appropriate consumers. It is very useful and comparable in data model
> bleed to candidate and running configuration in the base protocol work.
> 
> The idea here it to only specify the class and defer the content of the
> message to the datamodel. 


The WG will need to agree on the list on classes.
Currently there is no agreement.
This could take 3 - 6 extra months to reach
consensus on what the event types are allowed to be,
and the exact requirements and text related to each event type.

Putting some details in a non-normative appendix
instead of normative text is not acceptable.
It doesn't lessen the requirement for WG consensus
just because it's located in an appendix.


> 
> We still have the open discussion on what the initial set of values is
> and how they will be extended. There was discussion about a more
> URI-based extension instead of an enumerated list, but as was discussed,
> there are some serious disadvantages to this approach. This is similar
> to the enumerated list versus rowPointer debate we always had in SNMP.
> One-stop-shopping of enumerated lists provide much more ease of use and
> predictability then open-ended where-can-I-find-all-the-values things
> like URIs. URIs are good for big things like protocol operations and
> Schema namespace, but not for everything. Either way, putting the list
> in IANA seems reasonable.


Agreement on all semantics of all event classes is the key issue.
The form of the registry is irrelevant.


> --------------------------------------
> 
> <Andy>
> page 4:
> 
>    "discusses implications for the mapping of application protocols"
> 
> 
> Is this document doing to define the normative procedures
> for supporting notifications on each transport?  I think
> this would be better than generating 4 RFCs instead of 1,
> but the WG needs to decide where the normative transport-specific text
> will be located.
> </Andy>
> 
> The text is more there because it needs to be somewhere. I like the idea
> of updating the existing three transport documents (once they get
> published) then creating separate ones. 


I don't -- especially if notifications end up as
an optional capability.

> 
> 
> <Andy>
> ----------------
> 
> page 4:
> 
> NETCONF[NETCONF] --> NETCONF [NETCONF-PROTO]
> 
> ---------------
> 
> sec. 2:
> 
> There are no examples shown for each RPC operation.
> There should be examples here instead of spread out
> in the end of the document.
> 
> ----------------
> 
> page 6:
> 
> <create-subscription>
> 
> "This command .."
> 
> Wrong terminology.
> Use RPC method or operation.
> 
> -----------------
> </Andy>
> 
> ok
> 
> <Andy>
> 
> page 6:
> 
> <named-profile>
> 
> This is still an opaque, under-specified proprietary hack. There should
> be a read-write standard data model with standard parameters -- and
> nothing else.
> 
> I strongly object to this parameter.
> If vendors want to ignore the standard parameters
> and use their own instead, then XML already allows them to
> do that -- we should not help them hack around the standard within the
> standard itself.
> 
> </Andy>
> 
> Sorry? In the latest specification, the data model associated with the
> named profile is clearly defined. It's even read-write. What exactly is
> it you are looking for?


 From my reading of the text, examples, and XSD, it appears
this is not clearly defined.  Let's see what others think.
It looked to me that it didn't change much, except you added
a sentence that says there is supposed to be a schema that
tells the manager what is in the named profile.

I think we just need a plain data model that contains all of the configurable
parameters.   This data model must be the same for all implementations.
That's because this is supposed to be a standard.

The netconf protocol already has RPCs for manipulating data models,
already deals with all aspects of NV-storage, etc.
We don't need to introduce the concept of named profiles.
It's just more complexity without purpose.


> 
> ----------------
> 
> <Andy>
> 
> <notification>
> 
> Positive Response: no response, etc.
> 
> This only applies to RPCs, so it can be removed here.
> </Andy>
> 
> I disagree. I think it should be explicitly stated that there is no
> response. First of all, because we could have made these acknowledged
> events built on RPCs and second of all I still say the average reader
> thinks about the Netconf operations rather then the RPC analogy we have
> chosen to express them with. 


If there was a clearly specified architecture section, it would be
totally obvious how the notification "message flow" differed
from the RPC message flow.

      Positive Response : none

This doesn't really provide enough discussion of the message flow
or architecture.


> 
> ------------------
> 
> <Andy>
> notification examples in section 5:
> 
> It should be made clear they are only examples
> and are not normative.  The examples need to be explained
> as well.
> 
> These examples are unrealistic.
> I don't think it's proper for the agent to return a copy of all the
> config that actually changed in a 'config-change' notification. This
> could be really verbose, introduce access control problems, and it's not
> really needed anyway, if the NMS is designed correctly.
> </Andy>
> 
> We have added this disclaimer to other examples, but not those in
> section 5. We can do that. We have identified two types of configuration
> change events. The first provides more of a summary of changes in some
> useful format (new interface up or something) and the second would
> actually mirror the configuration command sent. The latter is necessary
> for security audit logs. 
> 
> Notifications always have access control issues. People need to have
> permission to see the data that is in the notifications.


I don't want to confuse implementors by implying in the
examples that including all the config sections that changed
in a notification is a good idea, or part of the standard.


> 
> ------------------
> 
> <Andy>
> schema comments
> 
> - an unspecified access control model is thrown in
>    with these 'minAccess' and 'maxAccess' <appinfo> additions.
>    There is no agreement in the WG on these XSD extensions,
>    or understanding of the functional requirements.
> 
> </Andy>
> 
> Yeah, that is a bit of a problem. We need this mechanism, but we don't
> have a standard one yet. So, we are using the one defined in
> http://www.ietf.org/internet-drafts/draft-chisholm-netconf-model-05.txt


Real big problem.
Won't get through the WG Chairs or the IESG.
It is not acceptable to block this document for unchartered work.
The min and max access allowed in terms of all netconf operations
will be defined in English text in a normative section.

The addition of <appInfo> elements for this purpose is not required,
not useful to off-the-shelf tools, and therefore not important.
The data models in NETCONF documents can be updated after
this sort of thing is standardized.


> 
> 
> -----------------
> <Andy>
> 
> filter example comments
> 
> Sec 6.2 introduces additional 'severity=foo' filtering syntax without
> really explaining it.
> 
> Not sure what this <neb> element is in the example.
> 
> <netconf:filter> is broken XML -- there is no 'netconf' prefix or an
> xmlns declared in the example.
> </Andy>
> 
> Hmmm. Need to look into these. 


The <neb> example is fairly broken.
There is no way to do an OR-expression on 1 field
like the example seems to imply.


> 
> ------------------
> 
> <Andy>
> section 7.1.1.1 session lifecycle
> 
> The WG did not discuss or approve any such feature.
> This watchdog-timer design doesn't work in a mixed-mode
> session very well.  The netconf agent never abruptly
> terminates a live session.  The lack of architecture discussion in this
> document jumps out in this section.  There is no mention of the agent
> constantly starting and tearing down sessions anywhere else.
> 
> This section needs to be removed.
> 
> </Andy>
> 
> Just the session lifecycle or the CallHome thing? Our understanding was
> that there was consensus to look at how to address the callHome thing
> and the session lifecycle is discussion related to that feature. If
> there is no consensus for the callHome thing, we can move it back to the
> design alternative appendix


I think the entire Callhome section is under-specified and
the whole approach is convoluted.  We already have NV-stored
data models in netconf. We could easily have a traditional
notification architecture without any subscription mechanism,
instead of an agent that connects to a manager and says
"ask me to start sending you notifications".

How does the agent know to ask?
Because it was configured in its NV-storage.
There could just as easily be the entire notification config
as well.

I've never met any operators who would rather miss critical
notifications than "risk" the wasted bandwidth of an agent sending
out critical alarms but nobody is listening.

It seems to me that holding all notifications
until some manager app reconnects after a reboot
and asks for them, amounts to a polling architecture.
It doesn't scale well either.



> 
> 
> --------------------
> 
> A.2 Lifecycle
> 
> This section is incorrect and needs to be removed.
> The NETCONF-PROT document already mandates certain
> non-volatile storage requirements.  This section
> contradicts that normative text.
> 
> </Andy>
> 
> We'll have to look into it. I suspect this is a misinterpretation of
> what is written rather then this design alternative was proposing
> something in violation of what is the in the PROTO draft.
> 
> ---------------------
> 
> <Andy>
> Appendix B: Syslog within NETCONF events
> 
> events --> notifications
> 
> This section does dot clearly define how to encode the
> XML PDU.  This should be a normative section (and fully
> specified) or removed from the document.
> 
> Notification forwarding options needs to be agreed upon
> by the WG, and fully explained in a detailed architecture section.
> 
> There is no proxy in netconf, and I aim to keep it that way.
> </Andy>
> 
> We were not sure if there was consensus for this feature to be moved to
> the main body of the document. We did add the new event class to support
> the tunnelling though.


The WG never even discussed this issue.
There was no discussion of adding new event classes,
only discussion of removing some event classes.

Now that the document is a WG-controlled document,
only changes that the WG agrees on are supposed to
show up in new versions.

Many vendors and operators at the IAB NM Workshop
were very clear in their request -- no proxy in netconf.
It was seen as complexity without purpose.


> 
> We don't specify how to encode any of the other event content. I don't
> know if we should be doing it for this one case.
> 
> ---------------------
> <Andy>
> 
> Appendix C: Example Configuration Notifications
> 
> This section needs to be removed.
> If the WG can agree of fully-specified standard notifications, then they
> will included in normative text.
> 
> </Andy>
> 
> While we did delete the sections that provided examples for
> non-configuration notifications, we were hesitant to delete this section
> because we actually referred to it during discussions last month. It
> might be useful to keep around for a bit longer.
> 
> 
> 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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 03 12:08:42 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbJu6-0000gl-9g
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 12:08:42 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbJu6-0006G3-74
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 12:08:42 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FbJu1-0006hW-9q
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 12:08:41 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbJpc-000M4Z-DI
	for netconf-data@psg.com; Wed, 03 May 2006 16:04:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1
Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <htrevino@cisco.com>)
	id 1FbJpT-000M3l-8r
	for netconf@ops.ietf.org; Wed, 03 May 2006 16:03:55 +0000
Received: from sj-core-4.cisco.com ([171.68.223.138])
  by sj-iport-4.cisco.com with ESMTP; 03 May 2006 09:03:54 -0700
X-IronPort-AV: i="4.05,85,1146466800"; 
   d="scan'208"; a="1800975340:sNHT35585296"
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k43G3sYg020901;
	Wed, 3 May 2006 09:03:54 -0700 (PDT)
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, 3 May 2006 09:03:54 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: comments on draft-ietf-netconf-notification-01.txt
Date: Wed, 3 May 2006 09:02:54 -0700
Message-ID: <6E21698722408147BEA594E073E2B0AB01CA0793@xmb-sjc-223.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: comments on draft-ietf-netconf-notification-01.txt
Thread-Index: AcZuD3o3a5pzNw59TTap8Sgml4canQAtS7wQ
From: "Hector Trevino \(htrevino\)" <htrevino@cisco.com>
To: "Andy Bierman" <ietf@andybierman.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 03 May 2006 16:03:54.0275 (UTC) FILETIME=[2D38C730:01C66ECB]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.6 (--)
X-Scan-Signature: f5932bfc8385127f631fc458a872feb1



Thanks for sending comments. See some responses in-line
Hector
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Tuesday, May 02, 2006 11:39 AM
> To: Netconf (E-mail)
> Subject: comments on draft-ietf-netconf-notification-01.txt
>=20
> Hi,
>=20
> This is not a full review.
> I'm still waiting for some WG members to do that.

HT: Could you please include the names of the reviewers so we get an
idea of what the various interested people are saying.

>=20
> -----------------------
>=20
> General comments:
>=20
>   - The draft still lacks any discussion of why we need this
>     document, what role it plays in the overall netconf architecture.

HT: Ok.=20
>=20
>   - The use of special RPCs, named profiles, and a read-only=20
> data model
>     goes against the core concept of netconf -- use the=20
> standard operations
>     to manipulate standard read-write data models.  The=20
> convoluted manner
>     in which a traditional notification generation=20
> application would be
>     realized would win a Rube Goldberg Machine Contest.
>=20
>     I strongly object to this design approach.

HT: The notification related RPCs give the user a convinient way to
request notification forwarding. While I agree that you could achieve
the same by using the NETCONF RPCs against a data model, such model does
not exist and there isn't much work in this area. Therefore, I don't see
how you can argue this point.=20

The named profiles provide a way to pre-configure subcription
information. What is the objection to this? In previous e-mails I
thought you also suggested having "profiles" with pre-configured
destinations. The idea is to allow for read/write access to the
subscription information.=20

>=20
>   - multiple subscriptions per session
>=20
>     I strongly object to this feature.
>     There is no rationale given for it.
>     Netconf has a single-user session model.
>     The NMS can use modify-subscription instead of creating multiple
>     subscriptions.  The NMS, not the agent, should provide this
>     additional, programmable classification service.  The complexity
>     added to the document to move this classification service to
>     the agent is unwarranted, and the feature is totally redundant.
>=20
>   - Event classes
>=20
>     I strongly object to this document defining the mandatory set of
>     event classifications.  This document should simply define a
>     field that contains a constrained string, which can be used for
>     filtering purposes.  The list still contains enumerations such as
>     'metrics' and 'heartbeat' which were supposed to be removed.
>     There are under-specified semantics and requirements for many
>     of these classifications.
>=20
>     The actual set of standard events is a modeling problem, and is
>     out of scope in this WG.

HT: I thought we had agreed to at least config change and syslog.=20
>=20
> --------------------------------------
>=20
> page 4:
>=20
>    "discusses implications for the mapping of application protocols"
>=20
>=20
> Is this document doing to define the normative procedures for=20
> supporting notifications on each transport?  I think this=20
> would be better than generating 4 RFCs instead of 1, but the=20
> WG needs to decide where the normative transport-specific=20
> text will be located.

HT: Ok=20
>=20
> ----------------
>=20
> page 4:
>=20
> NETCONF[NETCONF] --> NETCONF [NETCONF-PROTO]

HT: OK
>=20
> ---------------
>=20
> sec. 2:
>=20
> There are no examples shown for each RPC operation.
> There should be examples here instead of spread out in the=20
> end of the document.

HT: OK
>=20
> ----------------
>=20
> page 6:
>=20
> <create-subscription>
>=20
> "This command .."
>=20
> Wrong terminology.
> Use RPC method or operation.

HT: OK
>=20
> -----------------
>=20
> page 6:
>=20
> <named-profile>
>=20
> This is still an opaque, under-specified proprietary hack.
> There should be a read-write standard data model with=20
> standard parameters -- and nothing else.
>=20
> I strongly object to this parameter.
> If vendors want to ignore the standard parameters and use=20
> their own instead, then XML already allows them to do that --=20
> we should not help them hack around the standard within the=20
> standard itself.
>=20
> ----------------
>=20
>=20
> <notification>
>=20
> Positive Response: no response, etc.
>=20
> This only applies to RPCs, so it can be removed here.

HT: Ok =20
>=20
> ------------------
>=20
> notification examples in section 5:
>=20
> It should be made clear they are only examples and are not=20
> normative.  The examples need to be explained as well.
>=20
> These examples are unrealistic.
> I don't think it's proper for the agent to return a copy of=20
> all the config that actually changed in a 'config-change'=20
> notification.
> This could be really verbose, introduce access control=20
> problems, and it's not really needed anyway, if the NMS is=20
> designed correctly.

HT: OK, will update description. Regarding you second part of the
comment... the definition of a config change
notification allows for the inclusion (or not) of the changes that took
place. Depending on the managed device, this is actually a
desired/useful behavior. In some cases the device will send a change
notification with an ID & the management station may retrieve the
associated information. In other cases, the device will send all the
changes in a notification. I disagree the examples are unrealistic.=20
I think the comment on access control is too generic & this may or may
not be true depending on the deployment.=20

>=20
> ------------------
>=20
> schema comments
>=20
> - an unspecified access control model is thrown in
>    with these 'minAccess' and 'maxAccess' <appinfo> additions.
>    There is no agreement in the WG on these XSD extensions,
>    or understanding of the functional requirements.
>=20
> -----------------
>=20
> filter example comments
>=20
> Sec 6.2 introduces additional 'severity=3Dfoo' filtering syntax=20
> without really explaining it.

HT: OK, will add explanatory text
>=20
> Not sure what this <neb> element is in the example.

HT: It's just a tag to represent the top of a model that doesn't exist.
Same as top in the NETCONF examples. Will clarify.=20
>=20
> <netconf:filter> is broken XML -- there is no 'netconf'=20
> prefix or an xmlns declared in the example.

HT: No, it's not broken XML. It is correct based on the XSD that it was
generated against. Will update to make sure there is no
misunderstandings.=20
>=20
>=20
> ------------------
>=20
> section 7.1.1.1 session lifecycle
>=20
> The WG did not discuss or approve any such feature.
> This watchdog-timer design doesn't work in a mixed-mode=20
> session very well.  The netconf agent never abruptly=20
> terminates a live session.  The lack of architecture=20
> discussion in this document jumps out in this section.  There=20
> is no mention of the agent constantly starting and tearing=20
> down sessions anywhere else.
>=20
> This section needs to be removed.

HT: Will look at text=20

>=20
> ------------------
>=20
> Appendix A: Design Alternatives
>=20
> A.1 Suspend and Resume
>=20
> This section introduces even more complexity with new=20
> <suspend-subscription> and <resume-subscription> RPCs.
>=20
> I strongly object to all of these specialized RPCs.
> If we have a proper read-write data model, the standard=20
> operations such as <edit-config> provide all the=20
> configuration manipulation features we need.
>=20
> The agent already has code to implement <edit-config>.
> All of these special RPCs which are used to avoid=20
> <edit-config> add extra code and complexity to the agent.
>=20
> --------------------
>=20
> A.2 Lifecycle
>=20
> This section is incorrect and needs to be removed.
> The NETCONF-PROT document already mandates certain=20
> non-volatile storage requirements.  This section contradicts=20
> that normative text.
>=20
> ---------------------
>=20
> Appendix B: Syslog within NETCONF events
>=20
> events --> notifications
>=20
> This section does dot clearly define how to encode the XML=20
> PDU.  This should be a normative section (and fully
> specified) or removed from the document.
>=20
> Notification forwarding options needs to be agreed upon by=20
> the WG, and fully explained in a detailed architecture section.
>=20
> There is no proxy in netconf, and I aim to keep it that way.

HT: Ok. So can we agree to make updates and move this section into the
main body=20
>=20
> ---------------------
>=20
> Appendix C: Example Configuration Notifications
>=20
> This section needs to be removed.
> If the WG can agree of fully-specified standard=20
> notifications, then they will included in normative text.

HT: OK
>=20
> -------------------
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=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: <http://ops.ietf.org/lists/netconf/>
>=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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 03 12:36:22 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbKKs-0000Pj-A6
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 12:36:22 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbKKr-0007UV-Sd
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 12:36:22 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbKHG-000NnM-55
	for netconf-data@psg.com; Wed, 03 May 2006 16:32:38 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1
Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <htrevino@cisco.com>)
	id 1FbKHF-000Nn8-IY
	for netconf@ops.ietf.org; Wed, 03 May 2006 16:32:37 +0000
Received: from sj-core-5.cisco.com ([171.71.177.238])
  by sj-iport-4.cisco.com with ESMTP; 03 May 2006 09:32:37 -0700
X-IronPort-AV: i="4.05,85,1146466800"; 
   d="scan'208"; a="1800990228:sNHT32239356"
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 k43GWaRT020750;
	Wed, 3 May 2006 09:32:36 -0700 (PDT)
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);
	 Wed, 3 May 2006 09:32:36 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: comments on draft-ietf-netconf-notification-01.txt
Date: Wed, 3 May 2006 09:32:35 -0700
Message-ID: <6E21698722408147BEA594E073E2B0AB01CA07BE@xmb-sjc-223.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: comments on draft-ietf-netconf-notification-01.txt
Thread-Index: AcZuvDSCvpYM2Bd/RCGxgJx0xfouVQAD0abQ
From: "Hector Trevino \(htrevino\)" <htrevino@cisco.com>
To: "Andy Bierman" <ietf@andybierman.com>,
        "Sharon Chisholm" <schishol@nortel.com>
Cc: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 03 May 2006 16:32:36.0711 (UTC) FILETIME=[2FDFA770:01C66ECF]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86



--- cut ---=20

Question below.
Hector

>=20
> >=20
> >=20
> > -----------------
> > <Andy>
> >=20
> > filter example comments
> >=20
> > Sec 6.2 introduces additional 'severity=3Dfoo' filtering=20
> syntax without=20
> > really explaining it.
> >=20
> > Not sure what this <neb> element is in the example.
> >=20
> > <netconf:filter> is broken XML -- there is no 'netconf'=20
> prefix or an=20
> > xmlns declared in the example.
> > </Andy>
> >=20
> > Hmmm. Need to look into these.=20
>=20
>=20
> The <neb> example is fairly broken.
> There is no way to do an OR-expression on 1 field like the=20
> example seems to imply.
>=20
>=20

HT: Ok, perhaps this is a mis-interpretation of the subtree filtering
use. Reading the NETCONF text it appeared that the XML in the filter
example would be treated as an OR operation. If this is a
misinterpretation could you please clarify and point me to the
appropriate rule below.=20

In the example there is a node called "severity" which is repeated
multiple times with diff values. Looking at the list below, if this is
considered a "list" then the example is not valid, perhaps there are
others. Anyway, if you could clarify I'd appreciate it.
thanks



"6.2.5.  Content Match Nodes

   A leaf node which contains simple content is called a "content match
   node".  It is used to select some or all of its sibling nodes for
   filter output, and represents an exact-match filter on the leaf node
   element content.  The following constraints apply to content match
   nodes:

   o  A content match node must not contain nested elements (i.e., must
      resolve to a simpleType in XSD).

   o  Multiple content match nodes (i.e., sibling nodes) are logically
      combined in an "AND" expression.

   o  Filtering of mixed content is not supported.

   o  Filtering of list content is not supported.

   o  Filtering of whitespace-only content is not supported.
o  Leading and trailing whitespace characters are ignored, but any
      whitespace characters within a block of text characters are not
      ignored or modified.

   If all specified sibling content match nodes in a subtree filter
   expression are 'true', then the filter output nodes are selected in
   the following manner:

   o  Each content match node in the sibling set is included in the
      filter output.

   o  If any containment nodes are present in the sibling set then they
      are processed further, and included if any nested filter criteria
      are also met.

   o  If any selection nodes are present in the sibling set then all of
      them are included in the filter output.

   o  Otherwise (i.e., there are no selection or containment nodes in
      the filter sibling set) all the nodes defined at this level in the
      underlying data model (and their subtrees, if any) are returned in
      the filter output.

   If any of the sibling content match node tests are 'false', then no
   further filter processing is performed on that sibling set, and none
   of the sibling subtrees are selected by the filter, including the
   content match node(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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 03 12:48:40 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbKWm-0002Vp-0p
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 12:48:40 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbKWi-0007xN-B7
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 12:48:40 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbKSo-000Oah-Bb
	for netconf-data@psg.com; Wed, 03 May 2006 16:44:34 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FbKSm-000OaV-Qd
	for netconf@ops.ietf.org; Wed, 03 May 2006 16:44:33 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.hosting.dc2.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k43GiVHE016073
	for <netconf@ops.ietf.org>; Wed, 3 May 2006 12:44:32 -0400
Received: (qmail 29734 invoked by uid 78); 3 May 2006 16:44:31 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 3 May 2006 16:44:31 -0000
Message-ID: <4458DDE9.8030506@andybierman.com>
Date: Wed, 03 May 2006 09:44:25 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Hector Trevino (htrevino)" <htrevino@cisco.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: comments on draft-ietf-netconf-notification-01.txt
References: <6E21698722408147BEA594E073E2B0AB01CA0793@xmb-sjc-223.amer.cisco.com>
In-Reply-To: <6E21698722408147BEA594E073E2B0AB01CA0793@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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92

Hector Trevino (htrevino) wrote:
> 
> Thanks for sending comments. See some responses in-line
> Hector
>  
> 
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org 
>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
>> Sent: Tuesday, May 02, 2006 11:39 AM
>> To: Netconf (E-mail)
>> Subject: comments on draft-ietf-netconf-notification-01.txt
>>
>> Hi,
>>
>> This is not a full review.
>> I'm still waiting for some WG members to do that.
> 
> HT: Could you please include the names of the reviewers so we get an
> idea of what the various interested people are saying.


I wish I could, but this is a volunteer organization.
I have asked many people to do full reviews and to start
prototyping implementations.  I haven't received much
interest in either task.



> 
>> -----------------------
>>
>> General comments:
>>
>>   - The draft still lacks any discussion of why we need this
>>     document, what role it plays in the overall netconf architecture.
> 
> HT: Ok. 
>>   - The use of special RPCs, named profiles, and a read-only 
>> data model
>>     goes against the core concept of netconf -- use the 
>> standard operations
>>     to manipulate standard read-write data models.  The 
>> convoluted manner
>>     in which a traditional notification generation 
>> application would be
>>     realized would win a Rube Goldberg Machine Contest.
>>
>>     I strongly object to this design approach.
> 
> HT: The notification related RPCs give the user a convinient way to
> request notification forwarding. While I agree that you could achieve
> the same by using the NETCONF RPCs against a data model, such model does
> not exist and there isn't much work in this area. Therefore, I don't see
> how you can argue this point. 


I don't see how you could argue
that we should ignore all the standard
operations we just created in NETCONF-PROT.
The proposed special RPCs don't exist anymore
than a standard data model for configuration notifications.
It's less work to define data models for use with the
netconf protocol than it is to redefine the netconf protocol
functionality.



> 
> The named profiles provide a way to pre-configure subcription
> information. What is the objection to this? In previous e-mails I
> thought you also suggested having "profiles" with pre-configured
> destinations. The idea is to allow for read/write access to the
> subscription information. 


There is a big difference between a standard data model
with a set of standard parameters, and a standard pointer
off to some proprietary data model.


> 
>>   - multiple subscriptions per session
>>
>>     I strongly object to this feature.
>>     There is no rationale given for it.
>>     Netconf has a single-user session model.
>>     The NMS can use modify-subscription instead of creating multiple
>>     subscriptions.  The NMS, not the agent, should provide this
>>     additional, programmable classification service.  The complexity
>>     added to the document to move this classification service to
>>     the agent is unwarranted, and the feature is totally redundant.
>>
>>   - Event classes
>>
>>     I strongly object to this document defining the mandatory set of
>>     event classifications.  This document should simply define a
>>     field that contains a constrained string, which can be used for
>>     filtering purposes.  The list still contains enumerations such as
>>     'metrics' and 'heartbeat' which were supposed to be removed.
>>     There are under-specified semantics and requirements for many
>>     of these classifications.
>>
>>     The actual set of standard events is a modeling problem, and is
>>     out of scope in this WG.
> 
> HT: I thought we had agreed to at least config change and syslog. 


There is interest in this type of content.
Not wide consensus on any particular type of content,
but these seem to keep coming up in examples.


>> --------------------------------------
>>
>> page 4:
>>
>>    "discusses implications for the mapping of application protocols"
>>
>>
>> Is this document doing to define the normative procedures for 
>> supporting notifications on each transport?  I think this 
>> would be better than generating 4 RFCs instead of 1, but the 
>> WG needs to decide where the normative transport-specific 
>> text will be located.
> 
> HT: Ok 
>> ----------------
>>
>> page 4:
>>
>> NETCONF[NETCONF] --> NETCONF [NETCONF-PROTO]
> 
> HT: OK
>> ---------------
>>
>> sec. 2:
>>
>> There are no examples shown for each RPC operation.
>> There should be examples here instead of spread out in the 
>> end of the document.
> 
> HT: OK
>> ----------------
>>
>> page 6:
>>
>> <create-subscription>
>>
>> "This command .."
>>
>> Wrong terminology.
>> Use RPC method or operation.
> 
> HT: OK
>> -----------------
>>
>> page 6:
>>
>> <named-profile>
>>
>> This is still an opaque, under-specified proprietary hack.
>> There should be a read-write standard data model with 
>> standard parameters -- and nothing else.
>>
>> I strongly object to this parameter.
>> If vendors want to ignore the standard parameters and use 
>> their own instead, then XML already allows them to do that -- 
>> we should not help them hack around the standard within the 
>> standard itself.
>>
>> ----------------
>>
>>
>> <notification>
>>
>> Positive Response: no response, etc.
>>
>> This only applies to RPCs, so it can be removed here.
> 
> HT: Ok  
>> ------------------
>>
>> notification examples in section 5:
>>
>> It should be made clear they are only examples and are not 
>> normative.  The examples need to be explained as well.
>>
>> These examples are unrealistic.
>> I don't think it's proper for the agent to return a copy of 
>> all the config that actually changed in a 'config-change' 
>> notification.
>> This could be really verbose, introduce access control 
>> problems, and it's not really needed anyway, if the NMS is 
>> designed correctly.
> 
> HT: OK, will update description. Regarding you second part of the
> comment... the definition of a config change
> notification allows for the inclusion (or not) of the changes that took
> place. Depending on the managed device, this is actually a
> desired/useful behavior. In some cases the device will send a change
> notification with an ID & the management station may retrieve the
> associated information. In other cases, the device will send all the
> changes in a notification. I disagree the examples are unrealistic. 
> I think the comment on access control is too generic & this may or may
> not be true depending on the deployment. 


It seems to be a TimeFilter mechanism
(get all config that changed since time T)
is more useful than including all the changed
config in a notification.

Which products do this with notifications today?  None, AFAIK.


> 
>> ------------------
>>
>> schema comments
>>
>> - an unspecified access control model is thrown in
>>    with these 'minAccess' and 'maxAccess' <appinfo> additions.
>>    There is no agreement in the WG on these XSD extensions,
>>    or understanding of the functional requirements.
>>
>> -----------------
>>
>> filter example comments
>>
>> Sec 6.2 introduces additional 'severity=foo' filtering syntax 
>> without really explaining it.
> 
> HT: OK, will add explanatory text
>> Not sure what this <neb> element is in the example.
> 
> HT: It's just a tag to represent the top of a model that doesn't exist.
> Same as top in the NETCONF examples. Will clarify. 
>> <netconf:filter> is broken XML -- there is no 'netconf' 
>> prefix or an xmlns declared in the example.
> 
> HT: No, it's not broken XML. It is correct based on the XSD that it was
> generated against. Will update to make sure there is no
> misunderstandings. 



You have the same <event> subtree listed 3 times in the
filter example.  I'm not sure this is legal.


>>
>> ------------------
>>
>> section 7.1.1.1 session lifecycle
>>
>> The WG did not discuss or approve any such feature.
>> This watchdog-timer design doesn't work in a mixed-mode 
>> session very well.  The netconf agent never abruptly 
>> terminates a live session.  The lack of architecture 
>> discussion in this document jumps out in this section.  There 
>> is no mention of the agent constantly starting and tearing 
>> down sessions anywhere else.
>>
>> This section needs to be removed.
> 
> HT: Will look at text 
> 
>> ------------------
>>
>> Appendix A: Design Alternatives
>>
>> A.1 Suspend and Resume
>>
>> This section introduces even more complexity with new 
>> <suspend-subscription> and <resume-subscription> RPCs.
>>
>> I strongly object to all of these specialized RPCs.
>> If we have a proper read-write data model, the standard 
>> operations such as <edit-config> provide all the 
>> configuration manipulation features we need.
>>
>> The agent already has code to implement <edit-config>.
>> All of these special RPCs which are used to avoid 
>> <edit-config> add extra code and complexity to the agent.
>>
>> --------------------
>>
>> A.2 Lifecycle
>>
>> This section is incorrect and needs to be removed.
>> The NETCONF-PROT document already mandates certain 
>> non-volatile storage requirements.  This section contradicts 
>> that normative text.
>>
>> ---------------------
>>
>> Appendix B: Syslog within NETCONF events
>>
>> events --> notifications
>>
>> This section does dot clearly define how to encode the XML 
>> PDU.  This should be a normative section (and fully
>> specified) or removed from the document.
>>
>> Notification forwarding options needs to be agreed upon by 
>> the WG, and fully explained in a detailed architecture section.
>>
>> There is no proxy in netconf, and I aim to keep it that way.
> 
> HT: Ok. So can we agree to make updates and move this section into the
> main body 


No -- You can wait until the WG discusses it,
and if the WG wants it, it will move to a different section.


>> ---------------------
>>
>> Appendix C: Example Configuration Notifications
>>
>> This section needs to be removed.
>> If the WG can agree of fully-specified standard 
>> notifications, then they will included in normative text.
> 
> HT: OK
>> -------------------
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> to unsubscribe send a message to netconf-request@ops.ietf.org 
>> with the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
>>
> 
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 03 12:54:45 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbKcf-0005OG-0C
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 12:54:45 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbKcW-0008Kk-OC
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 12:54:44 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbKZF-000P6a-Fn
	for netconf-data@psg.com; Wed, 03 May 2006 16:51:13 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FbKZC-000P5d-3a
	for netconf@ops.ietf.org; Wed, 03 May 2006 16:51:10 +0000
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 278AC4F0001
	for <netconf@ops.ietf.org>; Wed,  3 May 2006 18:51:09 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 3 May 2006 18:51:08 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 3 May 2006 18:51:08 +0200
Message-ID: <4458DF7B.7050801@ericsson.com>
Date: Wed, 03 May 2006 18:51:07 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: comments on draft-ietf-netconf-notification-01.txt
References: <713043CE8B8E1348AF3C546DBE02C1B4083DCC34@zcarhxm2.corp.nortel.com> <4458B933.8090102@andybierman.com>
In-Reply-To: <4458B933.8090102@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 May 2006 16:51:08.0200 (UTC) FILETIME=[C65F6A80:01C66ED1]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2ed9477f79f24ff120e9894ad9dc9cb5

Sharon, first of all thanks for your efforts with the draft.

General comments:
1) We are not progressing well towards consensus so try to simplify the solution to get 
agreement faster.

2) Terminology: For me a subscription is a set of data that tells the netconf server where 
to send which notifications. This can be configured any way we like/decide. If this is not 
the correct term please propose a better name for it! ( I don't like named profile as it 
sounds too general.)
.
2) Data Model not new operations: I fully agree with Andy that we should use data models 
and the standard operations from netconf-prot and not introduce new operations (without 
very strong arguments, which I don't see here.)

I propose to upgrade the Named profiles into a standard data model for notification 
handling and use edit-config and get-config.
As a first step we need to agree that notifications should be handled with a data model 
and the only new operation needed is the notification itself. After this we can go on 
defining the data model itself. Can we get consensus on this?
!!!!!! THIS IS MY MAIN POINT. PLEASE ANSWER IT !!!!!!

This question is IMHO fully independent of the subscription, call-home, persistent 
profiles question.

3) Using both name profiles and session/subscription based filters is an overkill for me. 
I feel we have 2 separate mechanisms for the same function. I would just keep named 
profiles and drop the other filters in create-subscription, modify-subscription

4) We have the problem of long rpc-replies blocking the return channel for notifications. 
For this reason we discussed having a separate session for notifications. This does not 
appear in the draft. I think it should be there as an option.

5) For subscriptions I would propose to consider some extra data:
- persistent:boolean indicates whether the subscription is persistent or dies with the 
session.
- timeout:dateTime indicates whether this specific subscription should be removed if it is 
not used after a time (days, weeks). (garbage collection Jurgen asked for it, allowed to 
be set to infinity)
- suspended:boolean

6) Access Control: I feel we are not really dealing with access control here but rather 
stating what is meaningful on which bits of data e.g. do not try to write the operational 
state.

7) The draft does not address all requirements on Jurgen's page.

Section 1 somewhere)
Add text about:
- motivations, requirements (see Jurgen's web page)
- architecture of netconf Notifications (focus on notifications not on netconf-proto)
- mixed session, separate session

Section 2.2.1)
Mention that there might be a big chunk of user defined data here.

Section 3.2)
- Wrong name this is not a NetconfStateSchema but a netconfNotificationSchema or something 
  similar
- This data model should be writable as well, see general comment

Section 3.3)
I fully support a notification being a full XML document, but as far as I know with a SAX 
based parser you don't need a complete XML document to be able to process XML. Still life 
should be easier with complete XML documents.

Section 7)
I have a problem with the dormant-active state of the call home subscription. What is the 
real difference between them ?

Section 7.1)
When an event occurs and if we run the mixed-session mode the server should first check 
whether there is an already open connection to the client.

Section 7.1.1.1)
- Ericsson has a need for very long lived call home connections. We would probably put a 
heart-beat on the connection and this way never allow the connection to time-out. But I 
clearly see a need to put this time-out on separate sessions/individually.

Section 7.1.3.1.1)
The element subscriber is not really defined. Attributes like IpAddress, PortNumber etc. 
seem to be missing.

Appendix A)
I like the idea of suspend/resume but this should rather be a bit of data in the data 
model which can be set with edit-config.

Appendix B) Do we have a strong requirement for this ? I propose to remove it (or at least 
to delay ANY discussion of the feature after the time we agreed on basics).

regards Balazs

Andy Bierman wrote:
> Sharon Chisholm wrote:
>> hi
>>
>> Thanks for the review ....
>>
>> <Andy>
>>   - The use of special RPCs, named profiles, and a read-only data model
>>     goes against the core concept of netconf -- use the standard
>> operations
>>     to manipulate standard read-write data models.  The convoluted
>> manner
>>     in which a traditional notification generation application would be
>>     realized would win a Rube Goldberg Machine Contest.
>> </Andy>
>>
>> The subscription command is easier then other 'traditional' models for
>> the person doing the subscribing. We have modified the named profiles to
>> be a persistent set of information related to subscriptions for those
>> who are more interested in that approach. I'm hoping by 'traditional
>> notification generator' that you don't mean you wish to duplicate an
>> SNMP notification generator in Netconf. That model is one that we should
>> learn from and move on.
>>
>>
>> <Andy strongly objecting to multiple subscriptions per session>
>>
>> It seems more work to me to preclude it then allow it. There are
>> advantages to being able to organize two different sets of filters into
>> two different subscriptions.
>> <Andy>
>>   - Event classes
>>
>>     I strongly object to this document defining the mandatory set of
>>     event classifications.  This document should simply define a
>>     field that contains a constrained string, which can be used for
>>     filtering purposes.  The list still contains enumerations such as
>>     'metrics' and 'heartbeat' which were supposed to be removed.
>>     There are under-specified semantics and requirements for many
>>     of these classifications.
>>
>>     The actual set of standard events is a modeling problem, and is
>>     out of scope in this WG.
>>
>> </Andy>
>>
>> I strong support the inclusion of event classes in the document. I
>> thought we had agreed we had consensus that this was useful and should
>> be included? It lets the consumer of the message know what the content
>> will be and enables the receiver to route the notification to the
>> appropriate consumers. It is very useful and comparable in data model
>> bleed to candidate and running configuration in the base protocol work.
>>
>> The idea here it to only specify the class and defer the content of the
>> message to the datamodel. 
> 
> 
> The WG will need to agree on the list on classes.
> Currently there is no agreement.
> This could take 3 - 6 extra months to reach
> consensus on what the event types are allowed to be,
> and the exact requirements and text related to each event type.
> 
> Putting some details in a non-normative appendix
> instead of normative text is not acceptable.
> It doesn't lessen the requirement for WG consensus
> just because it's located in an appendix.
> 
> 
>>
>> We still have the open discussion on what the initial set of values is
>> and how they will be extended. There was discussion about a more
>> URI-based extension instead of an enumerated list, but as was discussed,
>> there are some serious disadvantages to this approach. This is similar
>> to the enumerated list versus rowPointer debate we always had in SNMP.
>> One-stop-shopping of enumerated lists provide much more ease of use and
>> predictability then open-ended where-can-I-find-all-the-values things
>> like URIs. URIs are good for big things like protocol operations and
>> Schema namespace, but not for everything. Either way, putting the list
>> in IANA seems reasonable.
> 
> 
> Agreement on all semantics of all event classes is the key issue.
> The form of the registry is irrelevant.
> 
> 
>> --------------------------------------
>>
>> <Andy>
>> page 4:
>>
>>    "discusses implications for the mapping of application protocols"
>>
>>
>> Is this document doing to define the normative procedures
>> for supporting notifications on each transport?  I think
>> this would be better than generating 4 RFCs instead of 1,
>> but the WG needs to decide where the normative transport-specific text
>> will be located.
>> </Andy>
>>
>> The text is more there because it needs to be somewhere. I like the idea
>> of updating the existing three transport documents (once they get
>> published) then creating separate ones. 
> 
> 
> I don't -- especially if notifications end up as
> an optional capability.
> 
>>
>>
>> <Andy>
>> ----------------
>>
>> page 4:
>>
>> NETCONF[NETCONF] --> NETCONF [NETCONF-PROTO]
>>
>> ---------------
>>
>> sec. 2:
>>
>> There are no examples shown for each RPC operation.
>> There should be examples here instead of spread out
>> in the end of the document.
>>
>> ----------------
>>
>> page 6:
>>
>> <create-subscription>
>>
>> "This command .."
>>
>> Wrong terminology.
>> Use RPC method or operation.
>>
>> -----------------
>> </Andy>
>>
>> ok
>>
>> <Andy>
>>
>> page 6:
>>
>> <named-profile>
>>
>> This is still an opaque, under-specified proprietary hack. There should
>> be a read-write standard data model with standard parameters -- and
>> nothing else.
>>
>> I strongly object to this parameter.
>> If vendors want to ignore the standard parameters
>> and use their own instead, then XML already allows them to
>> do that -- we should not help them hack around the standard within the
>> standard itself.
>>
>> </Andy>
>>
>> Sorry? In the latest specification, the data model associated with the
>> named profile is clearly defined. It's even read-write. What exactly is
>> it you are looking for?
> 
> 
>  From my reading of the text, examples, and XSD, it appears
> this is not clearly defined.  Let's see what others think.
> It looked to me that it didn't change much, except you added
> a sentence that says there is supposed to be a schema that
> tells the manager what is in the named profile.
> 
> I think we just need a plain data model that contains all of the 
> configurable
> parameters.   This data model must be the same for all implementations.
> That's because this is supposed to be a standard.
> 
> The netconf protocol already has RPCs for manipulating data models,
> already deals with all aspects of NV-storage, etc.
> We don't need to introduce the concept of named profiles.
> It's just more complexity without purpose.
> 
> 
>>
>> ----------------
>>
>> <Andy>
>>
>> <notification>
>>
>> Positive Response: no response, etc.
>>
>> This only applies to RPCs, so it can be removed here.
>> </Andy>
>>
>> I disagree. I think it should be explicitly stated that there is no
>> response. First of all, because we could have made these acknowledged
>> events built on RPCs and second of all I still say the average reader
>> thinks about the Netconf operations rather then the RPC analogy we have
>> chosen to express them with. 
> 
> 
> If there was a clearly specified architecture section, it would be
> totally obvious how the notification "message flow" differed
> from the RPC message flow.
> 
>      Positive Response : none
> 
> This doesn't really provide enough discussion of the message flow
> or architecture.
> 
> 
>>
>> ------------------
>>
>> <Andy>
>> notification examples in section 5:
>>
>> It should be made clear they are only examples
>> and are not normative.  The examples need to be explained
>> as well.
>>
>> These examples are unrealistic.
>> I don't think it's proper for the agent to return a copy of all the
>> config that actually changed in a 'config-change' notification. This
>> could be really verbose, introduce access control problems, and it's not
>> really needed anyway, if the NMS is designed correctly.
>> </Andy>
>>
>> We have added this disclaimer to other examples, but not those in
>> section 5. We can do that. We have identified two types of configuration
>> change events. The first provides more of a summary of changes in some
>> useful format (new interface up or something) and the second would
>> actually mirror the configuration command sent. The latter is necessary
>> for security audit logs.
>> Notifications always have access control issues. People need to have
>> permission to see the data that is in the notifications.
> 
> 
> I don't want to confuse implementors by implying in the
> examples that including all the config sections that changed
> in a notification is a good idea, or part of the standard.
> 
> 
>>
>> ------------------
>>
>> <Andy>
>> schema comments
>>
>> - an unspecified access control model is thrown in
>>    with these 'minAccess' and 'maxAccess' <appinfo> additions.
>>    There is no agreement in the WG on these XSD extensions,
>>    or understanding of the functional requirements.
>>
>> </Andy>
>>
>> Yeah, that is a bit of a problem. We need this mechanism, but we don't
>> have a standard one yet. So, we are using the one defined in
>> http://www.ietf.org/internet-drafts/draft-chisholm-netconf-model-05.txt
> 
> 
> Real big problem.
> Won't get through the WG Chairs or the IESG.
> It is not acceptable to block this document for unchartered work.
> The min and max access allowed in terms of all netconf operations
> will be defined in English text in a normative section.
> 
> The addition of <appInfo> elements for this purpose is not required,
> not useful to off-the-shelf tools, and therefore not important.
> The data models in NETCONF documents can be updated after
> this sort of thing is standardized.
> 
> 
>>
>>
>> -----------------
>> <Andy>
>>
>> filter example comments
>>
>> Sec 6.2 introduces additional 'severity=foo' filtering syntax without
>> really explaining it.
>>
>> Not sure what this <neb> element is in the example.
>>
>> <netconf:filter> is broken XML -- there is no 'netconf' prefix or an
>> xmlns declared in the example.
>> </Andy>
>>
>> Hmmm. Need to look into these. 
> 
> 
> The <neb> example is fairly broken.
> There is no way to do an OR-expression on 1 field
> like the example seems to imply.
> 
> 
>>
>> ------------------
>>
>> <Andy>
>> section 7.1.1.1 session lifecycle
>>
>> The WG did not discuss or approve any such feature.
>> This watchdog-timer design doesn't work in a mixed-mode
>> session very well.  The netconf agent never abruptly
>> terminates a live session.  The lack of architecture discussion in this
>> document jumps out in this section.  There is no mention of the agent
>> constantly starting and tearing down sessions anywhere else.
>>
>> This section needs to be removed.
>>
>> </Andy>
>>
>> Just the session lifecycle or the CallHome thing? Our understanding was
>> that there was consensus to look at how to address the callHome thing
>> and the session lifecycle is discussion related to that feature. If
>> there is no consensus for the callHome thing, we can move it back to the
>> design alternative appendix
> 
> 
> I think the entire Callhome section is under-specified and
> the whole approach is convoluted.  We already have NV-stored
> data models in netconf. We could easily have a traditional
> notification architecture without any subscription mechanism,
> instead of an agent that connects to a manager and says
> "ask me to start sending you notifications".
> 
> How does the agent know to ask?
> Because it was configured in its NV-storage.
> There could just as easily be the entire notification config
> as well.
> 
> I've never met any operators who would rather miss critical
> notifications than "risk" the wasted bandwidth of an agent sending
> out critical alarms but nobody is listening.
> 
> It seems to me that holding all notifications
> until some manager app reconnects after a reboot
> and asks for them, amounts to a polling architecture.
> It doesn't scale well either.
> 
> 
> 
>>
>>
>> --------------------
>>
>> A.2 Lifecycle
>>
>> This section is incorrect and needs to be removed.
>> The NETCONF-PROT document already mandates certain
>> non-volatile storage requirements.  This section
>> contradicts that normative text.
>>
>> </Andy>
>>
>> We'll have to look into it. I suspect this is a misinterpretation of
>> what is written rather then this design alternative was proposing
>> something in violation of what is the in the PROTO draft.
>>
>> ---------------------
>>
>> <Andy>
>> Appendix B: Syslog within NETCONF events
>>
>> events --> notifications
>>
>> This section does dot clearly define how to encode the
>> XML PDU.  This should be a normative section (and fully
>> specified) or removed from the document.
>>
>> Notification forwarding options needs to be agreed upon
>> by the WG, and fully explained in a detailed architecture section.
>>
>> There is no proxy in netconf, and I aim to keep it that way.
>> </Andy>
>>
>> We were not sure if there was consensus for this feature to be moved to
>> the main body of the document. We did add the new event class to support
>> the tunnelling though.
> 
> 
> The WG never even discussed this issue.
> There was no discussion of adding new event classes,
> only discussion of removing some event classes.
> 
> Now that the document is a WG-controlled document,
> only changes that the WG agrees on are supposed to
> show up in new versions.
> 
> Many vendors and operators at the IAB NM Workshop
> were very clear in their request -- no proxy in netconf.
> It was seen as complexity without purpose.
> 
> 
>>
>> We don't specify how to encode any of the other event content. I don't
>> know if we should be doing it for this one case.
>>
>> ---------------------
>> <Andy>
>>
>> Appendix C: Example Configuration Notifications
>>
>> This section needs to be removed.
>> If the WG can agree of fully-specified standard notifications, then they
>> will included in normative text.
>>
>> </Andy>
>>
>> While we did delete the sections that provided examples for
>> non-configuration notifications, we were hesitant to delete this section
>> because we actually referred to it during discussions last month. It
>> might be useful to keep around for a bit longer.
>>
>>
>> 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: <http://ops.ietf.org/lists/netconf/>

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 03 13:07:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbKop-0005Ux-9k
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 13:07:19 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbKop-0000ch-0W
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 13:07:19 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbKle-000Pqw-Tr
	for netconf-data@psg.com; Wed, 03 May 2006 17:04:02 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FbKlc-000Pqg-Pj
	for netconf@ops.ietf.org; Wed, 03 May 2006 17:04:00 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 852774F0014
	for <netconf@ops.ietf.org>; Wed,  3 May 2006 19:03:59 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 3 May 2006 19:03:59 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 3 May 2006 19:03:58 +0200
Message-ID: <4458E27E.80203@ericsson.com>
Date: Wed, 03 May 2006 19:03:58 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: comments on draft-ietf-netconf-notification-01.txt
References: <6E21698722408147BEA594E073E2B0AB01CA0793@xmb-sjc-223.amer.cisco.com> <4458DDE9.8030506@andybierman.com>
In-Reply-To: <4458DDE9.8030506@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 May 2006 17:03:59.0055 (UTC) FILETIME=[91D68DF0:01C66ED3]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014

We don't have a data model for notifications today, but sooner or later we will need to 
define some models. Why not start now? You already have a half data model in the 
notification draft.
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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 03 15:09:50 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbMjO-0005ce-Db
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 15:09:50 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbMjI-000607-TC
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 15:09:50 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbMcv-0006Cp-5P
	for netconf-data@psg.com; Wed, 03 May 2006 19:03:09 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FbMct-0006Cb-Aq
	for netconf@ops.ietf.org; Wed, 03 May 2006 19:03:07 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 4C22155D26;
	Wed,  3 May 2006 21:03:06 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 22557-06; Wed,  3 May 2006 21:03:04 +0200 (CEST)
Received: from boskop.local (unknown [10.222.1.3])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id 6938755FDA;
	Wed,  3 May 2006 21:03:04 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id 05CD16C9AB7; Wed,  3 May 2006 21:03:01 +0200 (CEST)
Date: Wed, 3 May 2006 21:03:01 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Andy Bierman <ietf@andybierman.com>
Cc: "Hector Trevino (htrevino)" <htrevino@cisco.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: comments on draft-ietf-netconf-notification-01.txt
Message-ID: <20060503190301.GA8800@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Andy Bierman <ietf@andybierman.com>,
	"Hector Trevino (htrevino)" <htrevino@cisco.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
References: <6E21698722408147BEA594E073E2B0AB01CA0793@xmb-sjc-223.amer.cisco.com> <4458DDE9.8030506@andybierman.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4458DDE9.8030506@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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f

On Wed, May 03, 2006 at 09:44:25AM -0700, Andy Bierman wrote:

> It's less work to define data models for use with the netconf
> protocol than it is to redefine the netconf protocol functionality.

I do not believe this to be true. Implementation wise, I actually do
not see much of a difference. My SNMP experience tells me that adding
new PDUs is actually not a big deal - implementing the semantics is
where you have to spend time. And having to check whether the data
elements you received make since is about the same work as checking
whether a PDU that you received makes sense.

<soap>
  Once upon a time, people believed that the addition of create/delete
  operations to SNMP would add a huge amount of complexity and so we
  got RowStatus which I assume every implementor who has gone through
  the 8K description clause has falled into deep love with.
</soap>

While I do not have a strong opinion, I do have a preference for a
_simple_ subscription mechanism as part of the protocol since I
believe having special verbs will make it more likely that management
apps get to actually use the feature. The argument is clearly on the
irrational side of things how I believe many human programmers work -
they usually tend prefer verbs over data structures and even purely
declarative approaches.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 03 15:42:02 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbNEY-0007Sd-N6
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 15:42:02 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbNEY-0006wG-B3
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 15:42:02 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbNBL-00087a-M2
	for netconf-data@psg.com; Wed, 03 May 2006 19:38:43 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FbNBK-00087H-II
	for netconf@ops.ietf.org; Wed, 03 May 2006 19:38:42 +0000
Received: from mail.networksolutionsemail.com (ns-omr6.mgt.hosting.dc2.netsol.com [10.49.6.69])
	by ns-omrbm6.netsolmail.com (8.13.6/8.13.6) with SMTP id k43Jcfdn022123
	for <netconf@ops.ietf.org>; Wed, 3 May 2006 15:38:41 -0400
Received: (qmail 13795 invoked by uid 78); 3 May 2006 19:38:41 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.69 with SMTP; 3 May 2006 19:38:41 -0000
Message-ID: <445906BB.2010305@andybierman.com>
Date: Wed, 03 May 2006 12:38:35 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>,
        "Hector Trevino (htrevino)" <htrevino@cisco.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: comments on draft-ietf-netconf-notification-01.txt
References: <6E21698722408147BEA594E073E2B0AB01CA0793@xmb-sjc-223.amer.cisco.com> <4458DDE9.8030506@andybierman.com> <20060503190301.GA8800@boskop.local>
In-Reply-To: <20060503190301.GA8800@boskop.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab

Juergen Schoenwaelder wrote:
> On Wed, May 03, 2006 at 09:44:25AM -0700, Andy Bierman wrote:
> 
>> It's less work to define data models for use with the netconf
>> protocol than it is to redefine the netconf protocol functionality.
> 
> I do not believe this to be true. Implementation wise, I actually do
> not see much of a difference. My SNMP experience tells me that adding
> new PDUs is actually not a big deal - implementing the semantics is
> where you have to spend time. And having to check whether the data
> elements you received make since is about the same work as checking
> whether a PDU that you received makes sense.
> 
> <soap>
>   Once upon a time, people believed that the addition of create/delete
>   operations to SNMP would add a huge amount of complexity and so we
>   got RowStatus which I assume every implementor who has gone through
>   the 8K description clause has falled into deep love with.
> </soap>
> 
> While I do not have a strong opinion, I do have a preference for a
> _simple_ subscription mechanism as part of the protocol since I
> believe having special verbs will make it more likely that management
> apps get to actually use the feature. The argument is clearly on the
> irrational side of things how I believe many human programmers work -
> they usually tend prefer verbs over data structures and even purely
> declarative approaches.
> 

There is always engineering trade-offs to consider.

I agree it will always be simpler on the NMS for
a particular task to use a specialized API that moves
complexity to the agent.  It is not simpler on the agent
to add new specialized code than it is to reuse existing code.

This approach doesn't scale well.
By the time you define 5 or 10 specialized RPCs for each
possible feature, you have 5000 special RPCs
and no reusable code.

We explicitly designed a protocol to provide
a small set of powerful standard operations which can
manipulate any arbitrary data model.
IMO, it is better to stick with this architecture
than ignore it and start on a path of specialized RPCs.


> /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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 03 16:18:29 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbNnp-0004KB-G1
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 16:18:29 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbNno-0000g9-2O
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 16:18:29 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbNiy-0009wS-H3
	for netconf-data@psg.com; Wed, 03 May 2006 20:13:28 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FbNiv-0009wB-PQ
	for netconf@ops.ietf.org; Wed, 03 May 2006 20:13:26 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 13D4855E5E;
	Wed,  3 May 2006 22:13:25 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 28930-10; Wed,  3 May 2006 22:13:23 +0200 (CEST)
Received: from boskop.local (unknown [10.222.1.3])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id 06CD155E91;
	Wed,  3 May 2006 22:13:23 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id 9DF796C9C07; Wed,  3 May 2006 22:13:20 +0200 (CEST)
Date: Wed, 3 May 2006 22:13:20 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Andy Bierman <ietf@andybierman.com>
Cc: "Hector Trevino (htrevino)" <htrevino@cisco.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: comments on draft-ietf-netconf-notification-01.txt
Message-ID: <20060503201320.GF8800@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Andy Bierman <ietf@andybierman.com>,
	"Hector Trevino (htrevino)" <htrevino@cisco.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
References: <6E21698722408147BEA594E073E2B0AB01CA0793@xmb-sjc-223.amer.cisco.com> <4458DDE9.8030506@andybierman.com> <20060503190301.GA8800@boskop.local> <445906BB.2010305@andybierman.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <445906BB.2010305@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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4

On Wed, May 03, 2006 at 12:38:35PM -0700, Andy Bierman wrote:
 
> There is always engineering trade-offs to consider.
> 
> I agree it will always be simpler on the NMS for
> a particular task to use a specialized API that moves
> complexity to the agent.  It is not simpler on the agent
> to add new specialized code than it is to reuse existing code.

I am not convinced that using a verb instead of a data model makes any
difference implementation wise on the agent. I accept that your
experience might be different from mine so we do not have to agree on
this.
 
> This approach doesn't scale well.
> By the time you define 5 or 10 specialized RPCs for each
> possible feature, you have 5000 special RPCs
> and no reusable code.

My background is work on DISMAN MIBs and I can assure you that the
fact that we had to cast every disman operation into gets/sets on a
data model did not make things simpler. In fact, it requires some
engineering efforts to cast out verbs from many data models that can
be provided as a library to be used by applications. In some MIBs, I
started to write down procedures how the various knobs should be used
to implement a verb. Here is also a quote from RFC 3535:

   -  Several standardized MIB modules lack a description of high-level
      procedures.  It is often not obvious from reading the MIB modules
      how certain high-level tasks are accomplished, which leads to
      several different ways to achieve the same goal, which increases
      costs and hinders interoperability.

I also note that CLIs tend to have lots of verbs and even though you
might not like this approach, they have at least been successful.
Note that I am not arguing we should open up pandora's box and add
verbs for everything (e.g. "shutdown interface" vs. "set interface
status down"). But we should also not fall into the other extreme
where we strictly stick to a fixed set of verbs just for purity
reasons or not very detailed claims of "increased complexity".

> We explicitly designed a protocol to provide
> a small set of powerful standard operations which can
> manipulate any arbitrary data model.
> IMO, it is better to stick with this architecture
> than ignore it and start on a path of specialized RPCs.

I thought we would have learned from SNMP's history and the success of
CLIs and that we would be a bit more flexible this time around and
take some of the irrational factors of humans also into account when
we design things.

Anyway, I think I stated my preference wrt. notification subscriptions
and if I am just a small minority who has some unusal implementation
experiences, I am fine to accept a more data driven approach (means I
will not object against it).

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 03 16:54:30 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbOMg-0001zG-A5
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 16:54:30 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbOMf-0002qO-QN
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 16:54:30 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbOHT-000Blf-VZ
	for netconf-data@psg.com; Wed, 03 May 2006 20:49:07 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [209.128.82.1] (helo=shell4.bayarea.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <dperkins@dsperkins.com>)
	id 1FbOHS-000BlP-RA
	for netconf@ops.ietf.org; Wed, 03 May 2006 20:49:06 +0000
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k43Kn3Ig008162;
	Wed, 3 May 2006 13:49:03 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k43Kn2tW008151;
	Wed, 3 May 2006 13:49:02 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Wed, 3 May 2006 13:49:02 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
cc: Andy Bierman <ietf@andybierman.com>,
        "Hector Trevino (htrevino)" <htrevino@cisco.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: comments on draft-ietf-netconf-notification-01.txt
In-Reply-To: <20060503201320.GF8800@boskop.local>
Message-ID: <Pine.LNX.4.10.10605031340490.4486-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be

HI,

I really agree with Juergen on this issue.

One thing that I would like to remind the readers about is
the following about creates.....

Consider a create operation. In some cases, the instance
of the item being created has a semantic meaning and
in other cases the instance is arbitrary. In other management
protocols, a create operation returns the instance of
the item being created. In the SNMP protocol, since
the designers did not provide "reliability", the result
of an operation could be lost. If the operation was
"create", then an instance could be created, but lost
when the result message was lost. Thus, to add a
create operation, the SNMP protocol would have to be
made "reliable". This is much harder, given the
installed base, than just adding a new verb.


On Wed, 3 May 2006, Juergen Schoenwaelder wrote:
> On Wed, May 03, 2006 at 12:38:35PM -0700, Andy Bierman wrote:
>  
> > There is always engineering trade-offs to consider.
> > 
> > I agree it will always be simpler on the NMS for
> > a particular task to use a specialized API that moves
> > complexity to the agent.  It is not simpler on the agent
> > to add new specialized code than it is to reuse existing code.
> 
> I am not convinced that using a verb instead of a data model makes any
> difference implementation wise on the agent. I accept that your
> experience might be different from mine so we do not have to agree on
> this.
>  
> > This approach doesn't scale well.
> > By the time you define 5 or 10 specialized RPCs for each
> > possible feature, you have 5000 special RPCs
> > and no reusable code.
> 
> My background is work on DISMAN MIBs and I can assure you that the
> fact that we had to cast every disman operation into gets/sets on a
> data model did not make things simpler. In fact, it requires some
> engineering efforts to cast out verbs from many data models that can
> be provided as a library to be used by applications. In some MIBs, I
> started to write down procedures how the various knobs should be used
> to implement a verb. Here is also a quote from RFC 3535:
> 
>    -  Several standardized MIB modules lack a description of high-level
>       procedures.  It is often not obvious from reading the MIB modules
>       how certain high-level tasks are accomplished, which leads to
>       several different ways to achieve the same goal, which increases
>       costs and hinders interoperability.
> 
> I also note that CLIs tend to have lots of verbs and even though you
> might not like this approach, they have at least been successful.
> Note that I am not arguing we should open up pandora's box and add
> verbs for everything (e.g. "shutdown interface" vs. "set interface
> status down"). But we should also not fall into the other extreme
> where we strictly stick to a fixed set of verbs just for purity
> reasons or not very detailed claims of "increased complexity".
> 
> > We explicitly designed a protocol to provide
> > a small set of powerful standard operations which can
> > manipulate any arbitrary data model.
> > IMO, it is better to stick with this architecture
> > than ignore it and start on a path of specialized RPCs.
> 
> I thought we would have learned from SNMP's history and the success of
> CLIs and that we would be a bit more flexible this time around and
> take some of the irrational factors of humans also into account when
> we design things.
> 
> Anyway, I think I stated my preference wrt. notification subscriptions
> and if I am just a small minority who has some unusal implementation
> experiences, I am fine to accept a more data driven approach (means I
> will not object against it).
> 
> /js
Regards,
/david t. perkins


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 03 17:39:58 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbP4g-0000m7-1F
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 17:39:58 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbP4f-0004EN-IU
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 17:39:58 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbOwf-000E0E-Ic
	for netconf-data@psg.com; Wed, 03 May 2006 21:31:41 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.51] (helo=ns-omrbm1.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FbOwc-000E00-Mm
	for netconf@ops.ietf.org; Wed, 03 May 2006 21:31:39 +0000
Received: from mail.networksolutionsemail.com (ns-omr1.mgt.hosting.dc2.netsol.com [10.49.6.64])
	by ns-omrbm1.netsolmail.com (8.13.6/8.13.6) with SMTP id k43LVbBg014976
	for <netconf@ops.ietf.org>; Wed, 3 May 2006 17:31:37 -0400
Received: (qmail 28395 invoked by uid 78); 3 May 2006 21:31:37 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.64 with SMTP; 3 May 2006 21:31:37 -0000
Message-ID: <44592133.3050302@andybierman.com>
Date: Wed, 03 May 2006 14:31:31 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>,
        "Hector Trevino (htrevino)" <htrevino@cisco.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: comments on draft-ietf-netconf-notification-01.txt
References: <6E21698722408147BEA594E073E2B0AB01CA0793@xmb-sjc-223.amer.cisco.com> <4458DDE9.8030506@andybierman.com> <20060503190301.GA8800@boskop.local> <445906BB.2010305@andybierman.com> <20060503201320.GF8800@boskop.local>
In-Reply-To: <20060503201320.GF8800@boskop.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 093efd19b5f651b2707595638f6c4003

Juergen Schoenwaelder wrote:
> On Wed, May 03, 2006 at 12:38:35PM -0700, Andy Bierman wrote:
>  
>> There is always engineering trade-offs to consider.
>>
>> I agree it will always be simpler on the NMS for
>> a particular task to use a specialized API that moves
>> complexity to the agent.  It is not simpler on the agent
>> to add new specialized code than it is to reuse existing code.
> 
> I am not convinced that using a verb instead of a data model makes any
> difference implementation wise on the agent. I accept that your
> experience might be different from mine so we do not have to agree on
> this.
>  
>> This approach doesn't scale well.
>> By the time you define 5 or 10 specialized RPCs for each
>> possible feature, you have 5000 special RPCs
>> and no reusable code.
> 
> My background is work on DISMAN MIBs and I can assure you that the
> fact that we had to cast every disman operation into gets/sets on a
> data model did not make things simpler. In fact, it requires some
> engineering efforts to cast out verbs from many data models that can
> be provided as a library to be used by applications. In some MIBs, I
> started to write down procedures how the various knobs should be used
> to implement a verb. Here is also a quote from RFC 3535:
> 
>    -  Several standardized MIB modules lack a description of high-level
>       procedures.  It is often not obvious from reading the MIB modules
>       how certain high-level tasks are accomplished, which leads to
>       several different ways to achieve the same goal, which increases
>       costs and hinders interoperability.
> 
> I also note that CLIs tend to have lots of verbs and even though you
> might not like this approach, they have at least been successful.
> Note that I am not arguing we should open up pandora's box and add
> verbs for everything (e.g. "shutdown interface" vs. "set interface
> status down"). But we should also not fall into the other extreme
> where we strictly stick to a fixed set of verbs just for purity
> reasons or not very detailed claims of "increased complexity".


Here is my concern.

We have zero standard data models now.
We have zero specialized RPCs now.

The notifications draft completely ignores all
of the write/save/reload operations in the protocol
and reinvents them with specialized RPCs instead.
Except they are under-specified and contradict
the protocol standard in some places (e.g., saying
NV-storage is optional).

I think a combined approach would be acceptable:

1) Define a data model for all the parameters that control/monitor
    the notification subscription, so that it can also be used by the
    agent without any manager subscription.  I.e., a table indexed by
    a name string containing one 'row' per parameter set.  A separate
    table for reusable filters is also needed.

    A notification target table is also needed which is completely
    independent of the session-subscription API.  Parameters such
    as the notification receiver address, user name, and user credentials
    need to be included to configure a traditional notification
    generation application.

2) Use standard operations such as <edit-config> to manipulate
    all notification parameters, even for changing profiles in use.
    <create-subscription> and all other special RPCs go away.

3) A new special RPC <start-notifications> is used
    for a manager to start receiving notifications.
    There is no subscription ID because there is only one
    stream of notifications on this session, which can be changed
    by editing the configuration.

    The <stop-notifications> RPC is used to tell the agent to
    cease notification generation for the session.

4) There is no real need for <suspend> and <resume> because
    the parameters passed in <start-notifications> are trivial.

5) mixed-mode vs. endless-RPC is very problematic.
    I could live with mixed-mode, but I don't want
    the WG coming back next year asking for a lot
    of complicated hacks to deal with the horrible
    operational characteristics of mixed-mode.
    The answer will be "don't mix operations and notifications
    if you are not prepared to deal with the delays or the lost
    notifications."



Andy



> 
>> We explicitly designed a protocol to provide
>> a small set of powerful standard operations which can
>> manipulate any arbitrary data model.
>> IMO, it is better to stick with this architecture
>> than ignore it and start on a path of specialized RPCs.
> 
> I thought we would have learned from SNMP's history and the success of
> CLIs and that we would be a bit more flexible this time around and
> take some of the irrational factors of humans also into account when
> we design things.
> 
> Anyway, I think I stated my preference wrt. notification subscriptions
> and if I am just a small minority who has some unusal implementation
> experiences, I am fine to accept a more data driven approach (means I
> will not object against it).
> 
> /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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 03 20:01:16 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbRHQ-0001ih-07
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 20:01:16 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbRHP-0002sJ-Jc
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 20:01:15 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbRAe-000LTs-4n
	for netconf-data@psg.com; Wed, 03 May 2006 23:54:16 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 required=5.0 tests=ADVANCE_FEE_1,AWL,BAYES_00,
	DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS autolearn=no version=3.1.1
Received: from [204.127.200.84] (helo=sccrmhc14.comcast.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <dbharrington@comcast.net>)
	id 1FbRAc-000LTh-Qq
	for netconf@ops.ietf.org; Wed, 03 May 2006 23:54:14 +0000
Received: from harrington73653 (c-24-128-66-70.hsd1.nh.comcast.net[24.128.66.70])
          by comcast.net (sccrmhc14) with SMTP
          id <20060503235412014001vvt2e>; Wed, 3 May 2006 23:54:13 +0000
From: "David B Harrington" <dbharrington@comcast.net>
To: <j.schoenwaelder@iu-bremen.de>,
	"'Andy Bierman'" <ietf@andybierman.com>
Cc: "'Netconf \(E-mail\)'" <netconf@ops.ietf.org>
Subject: RE: comments on draft-ietf-netconf-notification-01.txt
Date: Wed, 3 May 2006 19:53:32 -0400
Message-ID: <06dc01c66f0c$c8d3c410$0400a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
In-Reply-To: <20060503190301.GA8800@boskop.local>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4

Hi,
=20
> While I do not have a strong opinion, I do have a preference for a
> _simple_ subscription mechanism as part of the protocol since I
> believe having special verbs will make it more likely that
management
> apps get to actually use the feature. The argument is clearly on the
> irrational side of things how I believe many human programmers work
-
> they usually tend prefer verbs over data structures and even purely
> declarative approaches.
>=20

I am not an operator, so I cannot really state what operators would
prefer.
I am not a Netconf implenentor, so I cannot discuss implementation
issues.
I do not know XML or XSD very well, so cannot discuss
language-specific tradeoffs.
But I've heard complaints about SNMP for 13+ years, so I know about
that.
And I've been programming even longer, so I know about that.

One operator complaint is the data-centric rather than a task-based
approach of SNMP. People don't think in terms of "how should I
manipulate data sets to cause a side-effect to occur?", they think in
terms of "what do I need to do" to accomplish a task.

Programming languages migrated from binary to assembly to procedural
to object oriented designs.
Andy often complained about the peek-poke nature of SNMP. I associate
that approach with assembly language and its limited set of operations
that allowed one to peek/poke memory locations and registers.

I think a verb-based approach is associated with the more advanced
procedural style. I am of the impression that operators would prefer
to move from the antiquated peek-poke method of SNMP to a task-based
procedural approach (verb-based), akin to that used by CLI.=20

In a private email, somebody made this observation:
"In all my years of doing SNMP work, I never saw the
immediate uptake and commitment of real dollars to
an I-D, like I saw for netconf.  It's because dev-groups
all over were already migrating their CLI to XML, and all
doing it differently.  Netconf is all about CLI, not SNMP.
The SNMP people don't understand that yet. ;-)"

I think I understand that. If Netconf is all about CLI, then it
appears that support for a verb/task-based approach is called for,
rather than the data-centric peek-poke approach of SNMP.

Of course, with that decision comes the possibly-unconstrained growth
of verbs often found in CLIs.
But that's the price of progress, just as the unconstrained growth of
functions written in Fortran/Pascal/C/etc was the price one paid for
moving away from assembly language.

To be continued ...

dbh



--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 03 22:19:17 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbTQz-0004v8-Tj
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 22:19:17 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbTQz-0007p2-G1
	for netconf-archive@lists.ietf.org; Wed, 03 May 2006 22:19:17 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbTN8-0001rB-RC
	for netconf-data@psg.com; Thu, 04 May 2006 02:15:18 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=ADVANCE_FEE_1,AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FbTN7-0001qy-Dm
	for netconf@ops.ietf.org; Thu, 04 May 2006 02:15:17 +0000
Received: from mail.networksolutionsemail.com (ns-omr6.mgt.hosting.dc2.netsol.com [10.49.6.69])
	by ns-omrbm6.netsolmail.com (8.13.6/8.13.6) with SMTP id k442FGUf028682
	for <netconf@ops.ietf.org>; Wed, 3 May 2006 22:15:16 -0400
Received: (qmail 9980 invoked by uid 78); 4 May 2006 02:15:16 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.69 with SMTP; 4 May 2006 02:15:16 -0000
Message-ID: <445963AE.1050806@andybierman.com>
Date: Wed, 03 May 2006 19:15:10 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: David B Harrington <dbharrington@comcast.net>
CC: j.schoenwaelder@iu-bremen.de, "'Netconf (E-mail)'" <netconf@ops.ietf.org>
Subject: Re: comments on draft-ietf-netconf-notification-01.txt
References: <06dc01c66f0c$c8d3c410$0400a8c0@china.huawei.com>
In-Reply-To: <06dc01c66f0c$c8d3c410$0400a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813

David B Harrington wrote:
> Hi,


I don't understand why these comments were not
raised during the 4 years we were developing
a set of operations to manipulate XML data models.

Anyone who understands the power of arbitrarily
complex nested XML data knows that netconf is
quite a bit more powerful than SNMP + SMI.
It seems that some people want to give up on
data modeling before we even start.

Companies are implementing netconf because their
CLI is inappropriate for use as a programmatic API.
That doesn't mean they want to repeat all the
mistakes that were made in the CLI or SNMP.

Most of the features that have been declared so useful
by NMS developers on this list don't actually exist in
any NE products, because of the economics of SW engineering.
Mandating technology in an RFC isn't going change the
economics.

There is a big difference between an RPC like
<create-loopback-interface> (e.g., the agent picks the
interface instance identifier) which cannot be achieved any
other way, and RPCs that simply replicate the existing
functionality in the protocol for the perceived ease-of-use
by the NMS.



Andy


>  
>> While I do not have a strong opinion, I do have a preference for a
>> _simple_ subscription mechanism as part of the protocol since I
>> believe having special verbs will make it more likely that
> management
>> apps get to actually use the feature. The argument is clearly on the
>> irrational side of things how I believe many human programmers work
> -
>> they usually tend prefer verbs over data structures and even purely
>> declarative approaches.
>>
> 
> I am not an operator, so I cannot really state what operators would
> prefer.
> I am not a Netconf implenentor, so I cannot discuss implementation
> issues.
> I do not know XML or XSD very well, so cannot discuss
> language-specific tradeoffs.
> But I've heard complaints about SNMP for 13+ years, so I know about
> that.
> And I've been programming even longer, so I know about that.
> 
> One operator complaint is the data-centric rather than a task-based
> approach of SNMP. People don't think in terms of "how should I
> manipulate data sets to cause a side-effect to occur?", they think in
> terms of "what do I need to do" to accomplish a task.
> 
> Programming languages migrated from binary to assembly to procedural
> to object oriented designs.
> Andy often complained about the peek-poke nature of SNMP. I associate
> that approach with assembly language and its limited set of operations
> that allowed one to peek/poke memory locations and registers.
> 
> I think a verb-based approach is associated with the more advanced
> procedural style. I am of the impression that operators would prefer
> to move from the antiquated peek-poke method of SNMP to a task-based
> procedural approach (verb-based), akin to that used by CLI. 
> 
> In a private email, somebody made this observation:
> "In all my years of doing SNMP work, I never saw the
> immediate uptake and commitment of real dollars to
> an I-D, like I saw for netconf.  It's because dev-groups
> all over were already migrating their CLI to XML, and all
> doing it differently.  Netconf is all about CLI, not SNMP.
> The SNMP people don't understand that yet. ;-)"
> 
> I think I understand that. If Netconf is all about CLI, then it
> appears that support for a verb/task-based approach is called for,
> rather than the data-centric peek-poke approach of SNMP.
> 
> Of course, with that decision comes the possibly-unconstrained growth
> of verbs often found in CLIs.
> But that's the price of progress, just as the unconstrained growth of
> functions written in Fortran/Pascal/C/etc was the price one paid for
> moving away from assembly language.
> 
> To be continued ...
> 
> dbh
> 
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 04 03:43:41 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbYUv-0003No-SZ
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 03:43:41 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbYUs-0004mb-0A
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 03:43:41 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbYNU-0006bp-3m
	for netconf-data@psg.com; Thu, 04 May 2006 07:36:00 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FbYNS-0006bb-1M
	for netconf@ops.ietf.org; Thu, 04 May 2006 07:35:58 +0000
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B44335D4
	for <netconf@ops.ietf.org>; Thu,  4 May 2006 09:35:56 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 4 May 2006 09:35:56 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 4 May 2006 09:35:56 +0200
Message-ID: <4459AEDB.2020908@ericsson.com>
Date: Thu, 04 May 2006 09:35:55 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Notifications: data modeling or new operations ?
References: <6E21698722408147BEA594E073E2B0AB01CA0793@xmb-sjc-223.amer.cisco.com> <4458DDE9.8030506@andybierman.com> <20060503190301.GA8800@boskop.local> <445906BB.2010305@andybierman.com> <20060503201320.GF8800@boskop.local>
In-Reply-To: <20060503201320.GF8800@boskop.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 May 2006 07:35:56.0390 (UTC) FILETIME=[61665860:01C66F4D]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc

For me one main point is that a subscription (a set of data about where and what 
notifications to send) is real data that we want to keep for some time maybe even for a 
long time.

For complex operations we might need additional verbs/operations, but the subscription 
data is not so complex.

For operations where the main/sole aim is to produce a side effect (e.g. restart the node 
or start ping/traceroute tests) verbs may make more sense, but here we want to store the 
subscription data as well.

While I agree that using set operations sometimes can be unnatural way of handling objects 
I believe this is not the case for operations.

regards Balazs



Juergen Schoenwaelder wrote:
> On Wed, May 03, 2006 at 12:38:35PM -0700, Andy Bierman wrote:
>  
>> There is always engineering trade-offs to consider.
>>
>> I agree it will always be simpler on the NMS for
>> a particular task to use a specialized API that moves
>> complexity to the agent.  It is not simpler on the agent
>> to add new specialized code than it is to reuse existing code.
> 
> I am not convinced that using a verb instead of a data model makes any
> difference implementation wise on the agent. I accept that your
> experience might be different from mine so we do not have to agree on
> this.
>  
>> This approach doesn't scale well.
>> By the time you define 5 or 10 specialized RPCs for each
>> possible feature, you have 5000 special RPCs
>> and no reusable code.
> 
> My background is work on DISMAN MIBs and I can assure you that the
> fact that we had to cast every disman operation into gets/sets on a
> data model did not make things simpler. In fact, it requires some
> engineering efforts to cast out verbs from many data models that can
> be provided as a library to be used by applications. In some MIBs, I
> started to write down procedures how the various knobs should be used
> to implement a verb. Here is also a quote from RFC 3535:
> 
>    -  Several standardized MIB modules lack a description of high-level
>       procedures.  It is often not obvious from reading the MIB modules
>       how certain high-level tasks are accomplished, which leads to
>       several different ways to achieve the same goal, which increases
>       costs and hinders interoperability.
> 
> I also note that CLIs tend to have lots of verbs and even though you
> might not like this approach, they have at least been successful.
> Note that I am not arguing we should open up pandora's box and add
> verbs for everything (e.g. "shutdown interface" vs. "set interface
> status down"). But we should also not fall into the other extreme
> where we strictly stick to a fixed set of verbs just for purity
> reasons or not very detailed claims of "increased complexity".
> 
>> We explicitly designed a protocol to provide
>> a small set of powerful standard operations which can
>> manipulate any arbitrary data model.
>> IMO, it is better to stick with this architecture
>> than ignore it and start on a path of specialized RPCs.
> 
> I thought we would have learned from SNMP's history and the success of
> CLIs and that we would be a bit more flexible this time around and
> take some of the irrational factors of humans also into account when
> we design things.
> 
> Anyway, I think I stated my preference wrt. notification subscriptions
> and if I am just a small minority who has some unusal implementation
> experiences, I am fine to accept a more data driven approach (means I
> will not object against it).
> 
> /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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 04 03:49:03 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbYa7-0003c4-0E
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 03:49:03 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbYa4-0005BW-JY
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 03:49:02 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbYU7-0006xS-Rh
	for netconf-data@psg.com; Thu, 04 May 2006 07:42:51 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FbYU6-0006xC-Uz
	for netconf@ops.ietf.org; Thu, 04 May 2006 07:42:51 +0000
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B3FD3798
	for <netconf@ops.ietf.org>; Thu,  4 May 2006 09:42:49 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 4 May 2006 09:42:49 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 4 May 2006 09:42:49 +0200
Message-ID: <4459B078.2010005@ericsson.com>
Date: Thu, 04 May 2006 09:42:48 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notifications: data modeling or new operations ?
References: <6E21698722408147BEA594E073E2B0AB01CA0793@xmb-sjc-223.amer.cisco.com> <4458DDE9.8030506@andybierman.com> <20060503190301.GA8800@boskop.local> <445906BB.2010305@andybierman.com> <20060503201320.GF8800@boskop.local> <4459AEDB.2020908@ericsson.com>
In-Reply-To: <4459AEDB.2020908@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 May 2006 07:42:49.0570 (UTC) FILETIME=[57AC9C20:01C66F4E]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199

Balazs Lengyel wrote:

> While I agree that using set operations sometimes can be unnatural way 
> of handling objects I believe this is not the case for operations.
I MEAN FOR NOTIFICATIONS

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 04 06:32:29 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fbb8G-0006w4-Vv
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 06:32:28 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fbb8D-0003dr-Ka
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 06:32:28 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fbb1C-000FQ3-Gh
	for netconf-data@psg.com; Thu, 04 May 2006 10:25:10 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1Fbb1A-000FPL-OX
	for netconf@ops.ietf.org; Thu, 04 May 2006 10:25:09 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id C490355F9A;
	Thu,  4 May 2006 12:25:07 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 29782-01; Thu,  4 May 2006 12:25:05 +0200 (CEST)
Received: from boskop.local (unknown [10.50.250.214])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id 3BBF655FD9;
	Thu,  4 May 2006 12:25:04 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id E05FD6CA1C3; Thu,  4 May 2006 12:25:01 +0200 (CEST)
Date: Thu, 4 May 2006 12:25:01 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Andy Bierman <ietf@andybierman.com>
Cc: "Hector Trevino (htrevino)" <htrevino@cisco.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: comments on draft-ietf-netconf-notification-01.txt
Message-ID: <20060504102501.GA10929@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Andy Bierman <ietf@andybierman.com>,
	"Hector Trevino (htrevino)" <htrevino@cisco.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
References: <6E21698722408147BEA594E073E2B0AB01CA0793@xmb-sjc-223.amer.cisco.com> <4458DDE9.8030506@andybierman.com> <20060503190301.GA8800@boskop.local> <445906BB.2010305@andybierman.com> <20060503201320.GF8800@boskop.local> <44592133.3050302@andybierman.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <44592133.3050302@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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da

On Wed, May 03, 2006 at 02:31:31PM -0700, Andy Bierman wrote:
> I think a combined approach would be acceptable:
> 
> 1) Define a data model for all the parameters that control/monitor
>    the notification subscription, so that it can also be used by the
>    agent without any manager subscription.  I.e., a table indexed by
>    a name string containing one 'row' per parameter set.  A separate
>    table for reusable filters is also needed.
> 
>    A notification target table is also needed which is completely
>    independent of the session-subscription API.  Parameters such
>    as the notification receiver address, user name, and user credentials
>    need to be included to configure a traditional notification
>    generation application.
> 
> 2) Use standard operations such as <edit-config> to manipulate
>    all notification parameters, even for changing profiles in use.
>    <create-subscription> and all other special RPCs go away.
> 
> 3) A new special RPC <start-notifications> is used
>    for a manager to start receiving notifications.
>    There is no subscription ID because there is only one
>    stream of notifications on this session, which can be changed
>    by editing the configuration.
> 
>    The <stop-notifications> RPC is used to tell the agent to
>    cease notification generation for the session.
> 
> 4) There is no real need for <suspend> and <resume> because
>    the parameters passed in <start-notifications> are trivial.
> 
> 5) mixed-mode vs. endless-RPC is very problematic.
>    I could live with mixed-mode, but I don't want
>    the WG coming back next year asking for a lot
>    of complicated hacks to deal with the horrible
>    operational characteristics of mixed-mode.
>    The answer will be "don't mix operations and notifications
>    if you are not prepared to deal with the delays or the lost
>    notifications."

We should not compromise for the sake of a compromise.

What I am interested in is to have an easy mechanism to request that
notifications are directed to a given session (by default 'this'
session if we allow mixed content) and to have that request bound to
the lifetime of the session. In other words, I am thinking of a
subscription which establishes operational state rather than a change
of the configuration of the device and hence <edit-config> might not
be the primitive of choice.

You are looking for ways to configure persistent notificiation
receivers and I agree that this is essentially a configuration change
and so <edit-config> seems to be the appropriate primitive to use.

I think the first decision to take is whether the WG wants to support
both, one, or none of the use cases.

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 04 07:07:01 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fbbfh-0004Y1-RJ
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 07:07:01 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fbbfg-0005Q2-EQ
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 07:07:01 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbbYY-000Gzh-HW
	for netconf-data@psg.com; Thu, 04 May 2006 10:59:38 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1
Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1FbbYY-000GzU-1a
	for netconf@ops.ietf.org; Thu, 04 May 2006 10:59:38 +0000
Received: from sj-core-5.cisco.com ([171.71.177.238])
  by sj-iport-4.cisco.com with ESMTP; 04 May 2006 03:59:37 -0700
X-IronPort-AV: i="4.05,87,1146466800"; 
   d="scan'208"; a="1801271139:sNHT205896834"
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k44AxbRT013827;
	Thu, 4 May 2006 03:59:37 -0700 (PDT)
Received: from [144.254.22.202] (dhcp-wdata-vlan18-22-202.cisco.com [144.254.22.202])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k44Avslp030614;
	Thu, 4 May 2006 03:57:56 -0700
Message-ID: <4459DE95.5010707@cisco.com>
Date: Thu, 04 May 2006 12:59:33 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>,
        "Hector Trevino (htrevino)" <htrevino@cisco.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: comments on draft-ietf-netconf-notification-01.txt
References: <6E21698722408147BEA594E073E2B0AB01CA0793@xmb-sjc-223.amer.cisco.com> <4458DDE9.8030506@andybierman.com> <20060503190301.GA8800@boskop.local> <445906BB.2010305@andybierman.com> <20060503201320.GF8800@boskop.local> <44592133.3050302@andybierman.com> <20060504102501.GA10929@boskop.local>
In-Reply-To: <20060504102501.GA10929@boskop.local>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=1250; t=1146740277; x=1147604277;
	c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com>
	|Subject:Re=3A=20comments=20on=20draft-ietf-netconf-notification-01.txt
	|To:Andy=20Bierman=20<ietf@andybierman.com>,=20=0A=20=22Hector=20Trevino=20(
	htrevino)=22=20<htrevino@cisco.com>,=0A=20=22Netconf=20(E-mail)=22=20<netco
	nf@ops.ietf.org>;
	X=v=3Dcisco.com=3B=20h=3DVybBLlCTdCEEGqMBeJUHXxQQQQU=3D; b=W917vEkJV5yfd408Z/W5EjJlMCGUin8y/3Vp4nX8zCPcoiQtSMTRShnZJc1qLY5ObAvJj1Nk
	P3Q84H5kSxfry/4TcrSHIevnJ1k3llTI0IGb9qZgQTr2kC3oyIQz1t9P;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a

Juergen Schoenwaelder wrote:
> What I am interested in is to have an easy mechanism to request that
> notifications are directed to a given session (by default 'this'
> session if we allow mixed content) and to have that request bound to
> the lifetime of the session. In other words, I am thinking of a
> subscription which establishes operational state rather than a change
> of the configuration of the device and hence <edit-config> might not
> be the primitive of choice.
>
> You are looking for ways to configure persistent notificiation
> receivers and I agree that this is essentially a configuration change
> and so <edit-config> seems to be the appropriate primitive to use.
>
> I think the first decision to take is whether the WG wants to support
> both, one, or none of the use cases

I agree, and I don't think we should be too proscriptive with netconf
regarding new operations or anything else, except to say that if a
standard approach can be use it should be used as long as it isn't so
contorted as to end up with GET/SET for side effects, as Dave pointed out.

This having been said, perhaps there is a more general approach that we
should be considering than notifications, as to ephemeral state.

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 04 07:23:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbbvT-0000pl-Np
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 07:23:19 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbbvT-00060C-AI
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 07:23:19 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fbbpe-000HtR-Uj
	for netconf-data@psg.com; Thu, 04 May 2006 11:17:18 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fbbpd-000HtF-Pw
	for netconf@ops.ietf.org; Thu, 04 May 2006 11:17:17 +0000
Received: from mail.networksolutionsemail.com (ns-omr5.mgt.hosting.dc2.netsol.com [10.49.6.68])
	by ns-omrbm5.netsolmail.com (8.13.6/8.13.6) with SMTP id k44BHGh5005831
	for <netconf@ops.ietf.org>; Thu, 4 May 2006 07:17:17 -0400
Received: (qmail 24624 invoked by uid 78); 4 May 2006 11:17:16 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.68 with SMTP; 4 May 2006 11:17:16 -0000
Message-ID: <4459E2B6.3080707@andybierman.com>
Date: Thu, 04 May 2006 04:17:10 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>,
        "Hector Trevino (htrevino)" <htrevino@cisco.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: comments on draft-ietf-netconf-notification-01.txt
References: <6E21698722408147BEA594E073E2B0AB01CA0793@xmb-sjc-223.amer.cisco.com> <4458DDE9.8030506@andybierman.com> <20060503190301.GA8800@boskop.local> <445906BB.2010305@andybierman.com> <20060503201320.GF8800@boskop.local> <44592133.3050302@andybierman.com> <20060504102501.GA10929@boskop.local>
In-Reply-To: <20060504102501.GA10929@boskop.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b

Juergen Schoenwaelder wrote:
> On Wed, May 03, 2006 at 02:31:31PM -0700, Andy Bierman wrote:
>> I think a combined approach would be acceptable:

I think what Balazs and I are saying is that special RPCs
are fine when they are not merely replicating the functionality
of the standard operations.

This subscription info is just config data.
If it wasn't, you couldn't represent it in
the read-only data model (as in the document).

Since you can easily represent it as config data,
and since this approach allows both agent initiated
and manager initiated sessions to share the same config,
the standard operations (not special RPCs)
are the most correct choice.

I think enough people have spoken up
that we can say there is interest in
both manager and agent initiated notifications.


Andy

>>
>> 1) Define a data model for all the parameters that control/monitor
>>    the notification subscription, so that it can also be used by the
>>    agent without any manager subscription.  I.e., a table indexed by
>>    a name string containing one 'row' per parameter set.  A separate
>>    table for reusable filters is also needed.
>>
>>    A notification target table is also needed which is completely
>>    independent of the session-subscription API.  Parameters such
>>    as the notification receiver address, user name, and user credentials
>>    need to be included to configure a traditional notification
>>    generation application.
>>
>> 2) Use standard operations such as <edit-config> to manipulate
>>    all notification parameters, even for changing profiles in use.
>>    <create-subscription> and all other special RPCs go away.
>>
>> 3) A new special RPC <start-notifications> is used
>>    for a manager to start receiving notifications.
>>    There is no subscription ID because there is only one
>>    stream of notifications on this session, which can be changed
>>    by editing the configuration.
>>
>>    The <stop-notifications> RPC is used to tell the agent to
>>    cease notification generation for the session.
>>
>> 4) There is no real need for <suspend> and <resume> because
>>    the parameters passed in <start-notifications> are trivial.
>>
>> 5) mixed-mode vs. endless-RPC is very problematic.
>>    I could live with mixed-mode, but I don't want
>>    the WG coming back next year asking for a lot
>>    of complicated hacks to deal with the horrible
>>    operational characteristics of mixed-mode.
>>    The answer will be "don't mix operations and notifications
>>    if you are not prepared to deal with the delays or the lost
>>    notifications."
> 
> We should not compromise for the sake of a compromise.
> 
> What I am interested in is to have an easy mechanism to request that
> notifications are directed to a given session (by default 'this'
> session if we allow mixed content) and to have that request bound to
> the lifetime of the session. In other words, I am thinking of a
> subscription which establishes operational state rather than a change
> of the configuration of the device and hence <edit-config> might not
> be the primitive of choice.
> 
> You are looking for ways to configure persistent notificiation
> receivers and I agree that this is essentially a configuration change
> and so <edit-config> seems to be the appropriate primitive to use.
> 
> I think the first decision to take is whether the WG wants to support
> both, one, or none of the use cases.
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 04 08:32:34 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fbd0U-0006Bo-IX
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 08:32:34 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fbd0T-0000Bs-7w
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 08:32:34 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fbcro-000LbE-Ri
	for netconf-data@psg.com; Thu, 04 May 2006 12:23:36 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1Fbcrn-000Lax-9t
	for netconf@ops.ietf.org; Thu, 04 May 2006 12:23:35 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 9159C55ECC;
	Thu,  4 May 2006 14:23:34 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 12231-02; Thu,  4 May 2006 14:23:32 +0200 (CEST)
Received: from boskop.local (unknown [10.50.250.214])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id B32EB55C29;
	Thu,  4 May 2006 14:23:32 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id 4145E6CA26A; Thu,  4 May 2006 14:23:29 +0200 (CEST)
Date: Thu, 4 May 2006 14:23:29 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Andy Bierman <ietf@andybierman.com>
Cc: "Hector Trevino (htrevino)" <htrevino@cisco.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: comments on draft-ietf-netconf-notification-01.txt
Message-ID: <20060504122329.GB11032@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Andy Bierman <ietf@andybierman.com>,
	"Hector Trevino (htrevino)" <htrevino@cisco.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
References: <6E21698722408147BEA594E073E2B0AB01CA0793@xmb-sjc-223.amer.cisco.com> <4458DDE9.8030506@andybierman.com> <20060503190301.GA8800@boskop.local> <445906BB.2010305@andybierman.com> <20060503201320.GF8800@boskop.local> <44592133.3050302@andybierman.com> <20060504102501.GA10929@boskop.local> <4459E2B6.3080707@andybierman.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4459E2B6.3080707@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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa

On Thu, May 04, 2006 at 04:17:10AM -0700, Andy Bierman wrote:

> This subscription info is just config data.
> If it wasn't, you couldn't represent it in
> the read-only data model (as in the document).

For me, a subscription bound to the lifetime of a session just adds
operational state and does not constitute a configuration change of
the device. If I log into a CLI and I request the CLI to show log
messages in my ssh session, I do not really consider this to be a
configuration change activity.

> Since you can easily represent it as config data,
> and since this approach allows both agent initiated
> and manager initiated sessions to share the same config,
> the standard operations (not special RPCs)
> are the most correct choice.
 
In order to support dynamic subscriptions via <edit-config>, the data
model needs to provide appropriate 'short-cuts' in terms of special
values to point to a session rather than a target (or to a target
implicitely defined by a given existing session) and there must be
ways to distinguish between entries whose lifetime is bound to the
existence of something like a session and other permanent entries
and/or there need to be timers to help with garbage collection of
subscriptions of dead sessions. In other words, you have to add
features and some complexity to the data model to properly support
dynamic subscriptions if you go down the <edit-config> path and
consider a dynamic subscription to actually be a configuration change
of the device.

I simply find a <subscribe/> verb more natural for dynamic
subscriptions than doing a configuration change which has a limited
lifetime bound to some other operational state on the device, namely
the existance of the session.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 04 08:44:22 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbdBu-0000YC-11
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 08:44:22 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbdBt-00019I-An
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 08:44:22 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fbd6W-000MZF-4c
	for netconf-data@psg.com; Thu, 04 May 2006 12:38:48 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1Fbd6U-000MYq-Ip
	for netconf@ops.ietf.org; Thu, 04 May 2006 12:38:46 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 82CC54F0001
	for <netconf@ops.ietf.org>; Thu,  4 May 2006 14:38:45 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 4 May 2006 14:38:45 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 4 May 2006 14:38:45 +0200
Message-ID: <4459F5D4.3000301@ericsson.com>
Date: Thu, 04 May 2006 14:38:44 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: comments on draft-ietf-netconf-notification-01.txt
References: <6E21698722408147BEA594E073E2B0AB01CA0793@xmb-sjc-223.amer.cisco.com> <4458DDE9.8030506@andybierman.com> <20060503190301.GA8800@boskop.local> <445906BB.2010305@andybierman.com> <20060503201320.GF8800@boskop.local> <44592133.3050302@andybierman.com> <20060504102501.GA10929@boskop.local> <4459E2B6.3080707@andybierman.com> <20060504122329.GB11032@boskop.local>
In-Reply-To: <20060504122329.GB11032@boskop.local>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 May 2006 12:38:45.0234 (UTC) FILETIME=[AEDFED20:01C66F77]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a

If garbage collection is desirable it is anyway needed for the long term subscriptions.
You need a pointer to the session in the data structure as one target might have multiple 
sessions.

Juergen Schoenwaelder wrote:
> On Thu, May 04, 2006 at 04:17:10AM -0700, Andy Bierman wrote:
> 
>> This subscription info is just config data.
>> If it wasn't, you couldn't represent it in
>> the read-only data model (as in the document).
> 
> For me, a subscription bound to the lifetime of a session just adds
> operational state and does not constitute a configuration change of
> the device. If I log into a CLI and I request the CLI to show log
> messages in my ssh session, I do not really consider this to be a
> configuration change activity.
> 
Operational state could be part of the data model. Netconf-prot Section 1.3  title is 
Separation of Configuration and State Data. Also we need both dynamic and persistent 
subscriptions; we should have a common handling and persistent subscriptions are really data.

>> Since you can easily represent it as config data,
>> and since this approach allows both agent initiated
>> and manager initiated sessions to share the same config,
>> the standard operations (not special RPCs)
>> are the most correct choice.
>  
> In order to support dynamic subscriptions via <edit-config>, the data
> model needs to provide appropriate 'short-cuts' in terms of special
> values to point to a session rather than a target (or to a target
> implicitely defined by a given existing session) and there must be
> ways to distinguish between entries whose lifetime is bound to the
> existence of something like a session and other permanent entries
> and/or there need to be timers to help with garbage collection of
> subscriptions of dead sessions. In other words, you have to add
> features and some complexity to the data model to properly support
> dynamic subscriptions if you go down the <edit-config> path and
> consider a dynamic subscription to actually be a configuration change
> of the device.
Agree. This means two extra pieces of data for each subscription:
- related netconf session's sessionId
- garbage collection time or NIL
> 
> I simply find a <subscribe/> verb more natural for dynamic
> subscriptions than doing a configuration change which has a limited
> lifetime bound to some other operational state on the device, namely
> the existance of the session.
> 
> /js
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 04 09:13:11 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fbddn-0001FG-FR
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 09:13:11 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fbddl-0002aQ-2E
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 09:13:11 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbdYe-000OHG-B8
	for netconf-data@psg.com; Thu, 04 May 2006 13:07:52 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FbdYd-000OH5-GG
	for netconf@ops.ietf.org; Thu, 04 May 2006 13:07:51 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.hosting.dc2.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k44D7o4x022073
	for <netconf@ops.ietf.org>; Thu, 4 May 2006 09:07:51 -0400
Received: (qmail 16224 invoked by uid 78); 4 May 2006 13:07:50 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 4 May 2006 13:07:50 -0000
Message-ID: <4459FCA0.5010207@andybierman.com>
Date: Thu, 04 May 2006 06:07:44 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: notification configuration info model
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f

Hi,

Here is a simple "info model" for the notification data model.
This actually allows OR expressions to be processed correctly.


Filter Table - key: filterIndex

   filterIndex : Unsigned32 (1 .. max)

   filterDescr : string

   filterType : string ( andExpr, orExpr )

     # and-expr means all <filterPart> elements form a
     #   logical AND expression
     # or-expr means all <filterPart> elements form a
     #   logical OR expression

   filterPart : Component List (table) - key: filterPartIndex

        # nested table is just 'maxOccurs="unbounded"' in XML
        # 1 or more of these elements is needed to create a
        # meaningful filter

        filterPartIndex : Unsigned32 ( 1 .. max)

          # index is needed to avoid merge problem
          # entries will be evaluated in ascending order
          # sparse numbering is allowed

        filterPartType : string ( subtree, xpath, eventClass )

        filterPartVal : string



Profile Table - key: profileIndex

  profileIndex : Unsigned32 (1 .. max)

  profileDescr : string

  profileFilter : filterIndex

   # optional : if present then this filter entry is used
   #            A missing filter is the same as no filter



Target Table - key: targetName

  # this needs lots more work; it should be a generalized config
  # for all callhome purposes, not just agent-initiated notifications
  # this table is not used by the manager-session interface

  targetName : Name

  targetAddress : InetAddress

  targetUserName : string
 
  targetUserCredType : string

  targetUserCredential : string

 
--------------------------------

Example config:

<notifications>

  <filters>
    <filter>
      <filterIndex>1</filterIndex>
      <filterDescr>Filter for config or fault event types</filterDescr>
      <filterType>orExpr</filterType>
      <filterPart>
         <filterPartIndex>1</filterPartIndex>
         <filterPartType>eventClass</filterPartType>
         <filterPartVal>config</filterPartVal>
      </filterPart>
      <filterPart>
         <filterPartIndex>2</filterPartIndex>
         <filterPartType>eventClass</filterPartType>
         <filterPartVal>fault</filterPartVal>
      </filterPart>
    </filter>
   </filters>

   <profiles>
     <profile>
       <profileIndex>1</profileIndex>
       <profileDescr>Send only config and fault event classes</profileDescr>
       <profileFilter>1</profileFilter>
     </profile>
   </profiles>

</notifications>

-------------------------------------


For managers:

  <rpc>
    <start-notifications>
      <profile>1</profile>
    </start-notifications>
  </rpc>

For agents:

  - many issues very TBD like target priority,
    multiple targets, target fail-over
  - agent uses callhome mechanism to connect to manager;
    manager checks capabilities (need to figure out how
    the manager knows why the agent is connecting);
    manager uses <start-notifications> RPC to initiate
    notification generation.



     

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 04 09:25:55 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fbdq7-0007WJ-1P
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 09:25:55 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fbdq5-00039T-Kt
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 09:25:55 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbdmK-000P5l-7z
	for netconf-data@psg.com; Thu, 04 May 2006 13:22:00 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FbdmJ-000P5Z-Ep
	for netconf@ops.ietf.org; Thu, 04 May 2006 13:21:59 +0000
Received: from mail.networksolutionsemail.com (ns-omr5.mgt.hosting.dc2.netsol.com [10.49.6.68])
	by ns-omrbm5.netsolmail.com (8.13.6/8.13.6) with SMTP id k44DLusl011887
	for <netconf@ops.ietf.org>; Thu, 4 May 2006 09:21:58 -0400
Received: (qmail 3169 invoked by uid 78); 4 May 2006 13:21:56 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.68 with SMTP; 4 May 2006 13:21:56 -0000
Message-ID: <4459FFEE.6000103@andybierman.com>
Date: Thu, 04 May 2006 06:21:50 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>,
        "Hector Trevino (htrevino)" <htrevino@cisco.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: comments on draft-ietf-netconf-notification-01.txt
References: <6E21698722408147BEA594E073E2B0AB01CA0793@xmb-sjc-223.amer.cisco.com> <4458DDE9.8030506@andybierman.com> <20060503190301.GA8800@boskop.local> <445906BB.2010305@andybierman.com> <20060503201320.GF8800@boskop.local> <44592133.3050302@andybierman.com> <20060504102501.GA10929@boskop.local> <4459E2B6.3080707@andybierman.com> <20060504122329.GB11032@boskop.local>
In-Reply-To: <20060504122329.GB11032@boskop.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8

Juergen Schoenwaelder wrote:
> On Thu, May 04, 2006 at 04:17:10AM -0700, Andy Bierman wrote:
> 
>> This subscription info is just config data.
>> If it wasn't, you couldn't represent it in
>> the read-only data model (as in the document).
> 
> For me, a subscription bound to the lifetime of a session just adds
> operational state and does not constitute a configuration change of
> the device. If I log into a CLI and I request the CLI to show log
> messages in my ssh session, I do not really consider this to be a
> configuration change activity.


agreed; but the parameters used for filtering are
just config data.  There are valid use cases for
wanting to NV-store the filter data on the agent,
and wanting to share that config data amongst multiple sessions.


> 
>> Since you can easily represent it as config data,
>> and since this approach allows both agent initiated
>> and manager initiated sessions to share the same config,
>> the standard operations (not special RPCs)
>> are the most correct choice.
>  
> In order to support dynamic subscriptions via <edit-config>, the data
> model needs to provide appropriate 'short-cuts' in terms of special
> values to point to a session rather than a target (or to a target
> implicitely defined by a given existing session) and there must be
> ways to distinguish between entries whose lifetime is bound to the
> existence of something like a session and other permanent entries
> and/or there need to be timers to help with garbage collection of
> subscriptions of dead sessions. In other words, you have to add
> features and some complexity to the data model to properly support
> dynamic subscriptions if you go down the <edit-config> path and
> consider a dynamic subscription to actually be a configuration change
> of the device.
> 
> I simply find a <subscribe/> verb more natural for dynamic
> subscriptions than doing a configuration change which has a limited
> lifetime bound to some other operational state on the device, namely
> the existance of the session.


My proposal uses a <subscribe> verb.
It just does it in a way that maximizes
the reusability of the data and the protocol,
instead of reinventing the protocol.


> 
> /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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 04 10:01:33 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbeOb-0005wi-Pb
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 10:01:33 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbeOb-0004wA-Cs
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 10:01:33 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbeJm-0001R5-UD
	for netconf-data@psg.com; Thu, 04 May 2006 13:56:34 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=ADVANCE_FEE_1,AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.51] (helo=ns-omrbm1.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FbeJl-0001Qt-Ty
	for netconf@ops.ietf.org; Thu, 04 May 2006 13:56:34 +0000
Received: from mail.networksolutionsemail.com (ns-omr1.mgt.hosting.dc2.netsol.com [10.49.6.64])
	by ns-omrbm1.netsolmail.com (8.13.6/8.13.6) with SMTP id k44DuXZD013594
	for <netconf@ops.ietf.org>; Thu, 4 May 2006 09:56:33 -0400
Received: (qmail 14311 invoked by uid 78); 4 May 2006 13:56:32 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.64 with SMTP; 4 May 2006 13:56:32 -0000
Message-ID: <445A080B.5010006@andybierman.com>
Date: Thu, 04 May 2006 06:56:27 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: David B Harrington <dbharrington@comcast.net>
CC: j.schoenwaelder@iu-bremen.de, "'Netconf (E-mail)'" <netconf@ops.ietf.org>
Subject: Re: comments on draft-ietf-netconf-notification-01.txt
References: <06dc01c66f0c$c8d3c410$0400a8c0@china.huawei.com>
In-Reply-To: <06dc01c66f0c$c8d3c410$0400a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a

David B Harrington wrote:
>....
> I think a verb-based approach is associated with the more advanced
> procedural style. I am of the impression that operators would prefer
> to move from the antiquated peek-poke method of SNMP to a task-based
> procedural approach (verb-based), akin to that used by CLI. 
> 

I'm confused.
What do you think <edit-config> <get-config> <commit> etc. are?
These are the standard verbs in netconf.

For the configuration components of notification generation,
we already have a set of verbs.


> In a private email, somebody made this observation:
> "In all my years of doing SNMP work, I never saw the
> immediate uptake and commitment of real dollars to
> an I-D, like I saw for netconf.  It's because dev-groups
> all over were already migrating their CLI to XML, and all
> doing it differently.  Netconf is all about CLI, not SNMP.
> The SNMP people don't understand that yet. ;-)"
> 
> I think I understand that. If Netconf is all about CLI, then it
> appears that support for a verb/task-based approach is called for,
> rather than the data-centric peek-poke approach of SNMP.


I think clueful vendors will figure out that XML (not netconf)
allows them an opportunity to finally build the kind of
structure and metadata into their CLI tree they have wanted
for a long time.

Netconf provides the standard set of verbs on that XML config data.


> 
> Of course, with that decision comes the possibly-unconstrained growth
> of verbs often found in CLIs.
> But that's the price of progress, just as the unconstrained growth of
> functions written in Fortran/Pascal/C/etc was the price one paid for
> moving away from assembly language.


I know examples of SW that did not run amok
with specialized functions, and spent the extra effort to
keep code-size down, code consistency and reuse up.
This often happens in embedded NE development where the
hardware platform is resource limited and dictated in advance.

The mindset is that these NE devices are used for processing
packets, not XML documents.  IMO, embedded engineers will
never change -- their mission is to keep COGS costs down.
Adding hardware (such as memory) has to be cost-justified.
Moving lots of code from one cheap workstation to 1000's of
embedded agents is not usually done, for this very reason.


> 
> To be continued ...
> 
> dbh
> 
> 
> 
> 

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 04 10:37:44 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fbexc-0001kp-SN
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 10:37:44 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fbexb-0006Yx-JG
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 10:37:44 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fbet2-0003Yh-NW
	for netconf-data@psg.com; Thu, 04 May 2006 14:33:00 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.51] (helo=ns-omrbm1.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fbet1-0003YV-Tg
	for netconf@ops.ietf.org; Thu, 04 May 2006 14:33:00 +0000
Received: from mail.networksolutionsemail.com (ns-omr1.mgt.hosting.dc2.netsol.com [10.49.6.64])
	by ns-omrbm1.netsolmail.com (8.13.6/8.13.6) with SMTP id k44EWwR1024194
	for <netconf@ops.ietf.org>; Thu, 4 May 2006 10:32:59 -0400
Received: (qmail 20133 invoked by uid 78); 4 May 2006 14:32:12 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.64 with SMTP; 4 May 2006 14:32:12 -0000
Message-ID: <445A1067.5090901@andybierman.com>
Date: Thu, 04 May 2006 07:32:07 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: documentation requirements for event classes
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228

Hi,

In order to include a specific value in the
list of standard event classes, the following
requirements must be met:
 
  - WG consensus

  - detailed description of its purpose in the netconf protocol

  - detailed description of all manager and agent implementation
    requirements associated with the event class

  - It must be clear to developers how to determine that this
    is the appropriate event classification for a new notification type


The current draft has not had enough detailed review
to be able to complete item (1), but the other 3
requirements could be addressed right away.


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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 04 15:11:29 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbjEX-0002NV-Mg
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 15:11:29 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbjES-0001S9-5t
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 15:11:29 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fbj7t-000IT1-Us
	for netconf-data@psg.com; Thu, 04 May 2006 19:04:37 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1Fbj7s-000ISp-8S
	for netconf@ops.ietf.org; Thu, 04 May 2006 19:04:36 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 109395607D;
	Thu,  4 May 2006 21:04:35 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 22005-08; Thu,  4 May 2006 21:04:33 +0200 (CEST)
Received: from boskop.local (unknown [10.50.250.214])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id 4C3DA56064;
	Thu,  4 May 2006 21:04:33 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id 0618F6CAA11; Thu,  4 May 2006 21:04:30 +0200 (CEST)
Date: Thu, 4 May 2006 21:04:30 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Andy Bierman <ietf@andybierman.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: notification configuration info model
Message-ID: <20060504190430.GA11846@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Andy Bierman <ietf@andybierman.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
References: <4459FCA0.5010207@andybierman.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4459FCA0.5010207@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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c

On Thu, May 04, 2006 at 06:07:44AM -0700, Andy Bierman wrote:
 
> Here is a simple "info model" for the notification data model.
> This actually allows OR expressions to be processed correctly.

[...]
 
> For managers:
> 
>  <rpc>
>    <start-notifications>
>      <profile>1</profile>
>    </start-notifications>
>  </rpc>
> 
> For agents:
> 
>  - many issues very TBD like target priority,
>    multiple targets, target fail-over
>  - agent uses callhome mechanism to connect to manager;
>    manager checks capabilities (need to figure out how
>    the manager knows why the agent is connecting);
>    manager uses <start-notifications> RPC to initiate
>    notification generation.

If I understand things correctly, you want to use <edit-config> as the
only means to configure notification filters and profiles (not sure we
actually need both or what the added value of a profile is over just a
filter) and <start-notifications> <stop-notifications> verbs for
dynamic subscriptions. This approach and devision of work is fine with
me.

/js

PS. With ISMS in mind, we should think about impact of the asymmetry
    of SSH authentication and how that applies to access control. Well,
    netconf currently does not spell out access control so this is not
    really part of the WG concerns a this time. However, I think it
    would be desirable that ISMS and netconf use the same model when
    it comes down to "agent" initiated sessions for the delivery of
    notifications and how you bind access control rules to authenticated
    identities.

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 04 16:42:59 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fbkf5-0007kE-4L
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 16:42:59 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fbkf3-00070a-Nk
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 16:42:59 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fbkb7-000Noz-NS
	for netconf-data@psg.com; Thu, 04 May 2006 20:38:53 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [130.59.4.87] (helo=diotima.switch.ch)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <simon@limmat.switch.ch>)
	id 1Fbkb6-000Nol-6x
	for netconf@ops.ietf.org; Thu, 04 May 2006 20:38:52 +0000
Received: from localhost.localdomain (localhost [IPv6:::1])
	by diotima.switch.ch (8.13.5+Sun/8.13.5) with ESMTP id k44Kcj7v006853;
	Thu, 4 May 2006 22:38:45 +0200 (CEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17498.26184.150982.198748@localhost.localdomain>
Date: Thu, 4 May 2006 22:38:32 +0200
From: Simon Leinen <simon@limmat.switch.ch>
To: netconf@ops.ietf.org
Subject: IETF 65 Meeting Survey (request on behalf of the IAD)
X-Mailer: VM 7.19 under Emacs 22.0.50.1
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab

For all of you who attended the Dallas IETF meeting (and haven't
filled in the survey yet), here's a message the IETF Administrative
Director asked us to relay.  Please take a few minutes to make your
opinions known.  Thanks-- Simon.

----------------------------------------------------------------------
The IAD is interested in your IETF 65 meeting experience, whether you
participated  in Dallas or remotely.  The information will be used to improve
future meetings.  Your participation is anonymous and your candor is most
welcome.  
Thanks for taking part in this brief survey: 
http://www.surveymonkey.com/s.asp?u=649182049947

Ray Pelletier
IAD
iad at ietf.org
----------------------------------------------------------------------

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 04 18:05:39 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fblx5-0001OA-2c
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 18:05:39 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fblx4-00010m-OK
	for netconf-archive@lists.ietf.org; Thu, 04 May 2006 18:05:39 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FblsA-0001eQ-F3
	for netconf-data@psg.com; Thu, 04 May 2006 22:00:34 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fbls9-0001eE-Bs
	for netconf@ops.ietf.org; Thu, 04 May 2006 22:00:33 +0000
Received: from mail.networksolutionsemail.com (ns-omr5.mgt.hosting.dc2.netsol.com [10.49.6.68])
	by ns-omrbm5.netsolmail.com (8.13.6/8.13.6) with SMTP id k44M0WO9017653
	for <netconf@ops.ietf.org>; Thu, 4 May 2006 18:00:32 -0400
Received: (qmail 8395 invoked by uid 78); 4 May 2006 22:00:32 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.68 with SMTP; 4 May 2006 22:00:32 -0000
Message-ID: <445A797A.7000501@andybierman.com>
Date: Thu, 04 May 2006 15:00:26 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: notification configuration info model
References: <4459FCA0.5010207@andybierman.com> <20060504190430.GA11846@boskop.local>
In-Reply-To: <20060504190430.GA11846@boskop.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135

Juergen Schoenwaelder wrote:
> On Thu, May 04, 2006 at 06:07:44AM -0700, Andy Bierman wrote:
>  
>> Here is a simple "info model" for the notification data model.
>> This actually allows OR expressions to be processed correctly.
> 
> [...]
>  
>> For managers:
>>
>>  <rpc>
>>    <start-notifications>
>>      <profile>1</profile>
>>    </start-notifications>
>>  </rpc>
>>
>> For agents:
>>
>>  - many issues very TBD like target priority,
>>    multiple targets, target fail-over
>>  - agent uses callhome mechanism to connect to manager;
>>    manager checks capabilities (need to figure out how
>>    the manager knows why the agent is connecting);
>>    manager uses <start-notifications> RPC to initiate
>>    notification generation.
> 
> If I understand things correctly, you want to use <edit-config> as the
> only means to configure notification filters and profiles (not sure we
> actually need both or what the added value of a profile is over just a
> filter) and <start-notifications> <stop-notifications> verbs for
> dynamic subscriptions. This approach and devision of work is fine with
> me.

Yes.
I imagine a profile will end up with more parameters
than the filter index.  If not, the profile table can
be removed.


> 
> /js
> 
> PS. With ISMS in mind, we should think about impact of the asymmetry
>     of SSH authentication and how that applies to access control. Well,
>     netconf currently does not spell out access control so this is not
>     really part of the WG concerns a this time. However, I think it
>     would be desirable that ISMS and netconf use the same model when
>     it comes down to "agent" initiated sessions for the delivery of
>     notifications and how you bind access control rules to authenticated
>     identities.
> 

I have been on the 'security bandwagon' for a long time.
I wanted to work on access control, naming, and partial locks
before notifications.


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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 05 07:29:03 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FbyUZ-00032t-Nh
	for netconf-archive@lists.ietf.org; Fri, 05 May 2006 07:29:03 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FbyUZ-0007Yt-Du
	for netconf-archive@lists.ietf.org; Fri, 05 May 2006 07:29:03 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FbyLp-000ISH-CX
	for netconf-data@psg.com; Fri, 05 May 2006 11:20:01 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [198.152.13.103] (helo=co300216-ier2.net.avaya.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1FbyLo-000IRe-L1
	for netconf@ops.ietf.org; Fri, 05 May 2006 11:20:00 +0000
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k45BJPR2018535
	for <netconf@ops.ietf.org>; Fri, 5 May 2006 07:19:26 -0400
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: documentation requirements for event classes
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Date: Fri, 5 May 2006 14:19:56 +0300
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A72C51B@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: documentation requirements for event classes
Thread-Index: AcZvh9PTtq8vhfonTnSDohfgvv+NpgApKesw
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Andy Bierman" <ietf@andybierman.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44

Andy,

Can you clarify what you mean by ' the other 3 requirements could be
addressed right away'? Do you mean there is enough information in the
draft already, or there is not enough information and you suggest that
this be addressed in the next iteration of the draft, or do you believe
that there is a need for a separate document, or something else?=20

Dan


=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Thursday, May 04, 2006 5:32 PM
> To: Netconf (E-mail)
> Subject: documentation requirements for event classes
>=20
> Hi,
>=20
> In order to include a specific value in the list of standard=20
> event classes, the following requirements must be met:
> =20
>   - WG consensus
>=20
>   - detailed description of its purpose in the netconf protocol
>=20
>   - detailed description of all manager and agent implementation
>     requirements associated with the event class
>=20
>   - It must be clear to developers how to determine that this
>     is the appropriate event classification for a new=20
> notification type
>=20
>=20
> The current draft has not had enough detailed review to be=20
> able to complete item (1), but the other 3 requirements could=20
> be addressed right away.
>=20
>=20
> Andy
>=20
>=20
>=20
>=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: <http://ops.ietf.org/lists/netconf/>
>=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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 05 10:46:36 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fc1Zk-0002fu-6u
	for netconf-archive@lists.ietf.org; Fri, 05 May 2006 10:46:36 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fc1Zj-000744-Tc
	for netconf-archive@lists.ietf.org; Fri, 05 May 2006 10:46:36 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fc1VM-0005Nt-0t
	for netconf-data@psg.com; Fri, 05 May 2006 14:42:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fc1VK-0005Nf-Tg
	for netconf@ops.ietf.org; Fri, 05 May 2006 14:42:03 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.hosting.dc2.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k45Eg1MF026923
	for <netconf@ops.ietf.org>; Fri, 5 May 2006 10:42:02 -0400
Received: (qmail 7351 invoked by uid 78); 5 May 2006 14:41:52 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 5 May 2006 14:41:52 -0000
Message-ID: <445B642A.2090906@andybierman.com>
Date: Fri, 05 May 2006 07:41:46 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: documentation requirements for event classes
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0A72C51B@is0004avexu1.global.avaya.com>
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2F0A72C51B@is0004avexu1.global.avaya.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81

Romascanu, Dan (Dan) wrote:
> Andy,
> 
> Can you clarify what you mean by ' the other 3 requirements could be
> addressed right away'? Do you mean there is enough information in the
> draft already, or there is not enough information and you suggest that
> this be addressed in the next iteration of the draft, or do you believe
> that there is a need for a separate document, or something else? 

I should have been more clear.
We can't reach WG consensus on an event type
until the 3 documentation parts are done
for that event type, so people know enough
about it to make a choice.


> 
> Dan

Andy

> 
> 
>  
>  
> 
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org 
>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
>> Sent: Thursday, May 04, 2006 5:32 PM
>> To: Netconf (E-mail)
>> Subject: documentation requirements for event classes
>>
>> Hi,
>>
>> In order to include a specific value in the list of standard 
>> event classes, the following requirements must be met:
>>  
>>   - WG consensus
>>
>>   - detailed description of its purpose in the netconf protocol
>>
>>   - detailed description of all manager and agent implementation
>>     requirements associated with the event class
>>
>>   - It must be clear to developers how to determine that this
>>     is the appropriate event classification for a new 
>> notification type
>>
>>
>> The current draft has not had enough detailed review to be 
>> able to complete item (1), but the other 3 requirements could 
>> be addressed right away.
>>
>>
>> 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: <http://ops.ietf.org/lists/netconf/>
>>
> 
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 05 10:55:29 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fc1iL-0008Cs-9p
	for netconf-archive@lists.ietf.org; Fri, 05 May 2006 10:55:29 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fc1iK-0007Sz-N3
	for netconf-archive@lists.ietf.org; Fri, 05 May 2006 10:55:29 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fc1fF-0006Fr-Ck
	for netconf-data@psg.com; Fri, 05 May 2006 14:52:17 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FbbN8-000GUC-M9
	for netconf@ops.ietf.org; Thu, 04 May 2006 10:47:51 +0000
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CB10E7C0
	for <netconf@ops.ietf.org>; Thu,  4 May 2006 12:47:49 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 4 May 2006 12:47:49 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 4 May 2006 12:47:49 +0200
Message-ID: <4459DBD4.8080302@ericsson.com>
Date: Thu, 04 May 2006 12:47:48 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: comments on draft-ietf-netconf-notification-01.txt
References: <6E21698722408147BEA594E073E2B0AB01CA0793@xmb-sjc-223.amer.cisco.com> <4458DDE9.8030506@andybierman.com> <20060503190301.GA8800@boskop.local> <445906BB.2010305@andybierman.com> <20060503201320.GF8800@boskop.local> <44592133.3050302@andybierman.com> <20060504102501.GA10929@boskop.local>
In-Reply-To: <20060504102501.GA10929@boskop.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 May 2006 10:47:49.0516 (UTC) FILETIME=[2FC1F4C0:01C66F68]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb

In the current draft even short lived subscriptions (session based) can be queried 
(Section 3.2) so to me they seem to be data.

In Ericsson we need  persistent receivers. Imagine a management station that manages 5000 
  nodes. When the management station restarts it does not want to go and subscribe 5000 
times if this can be avoided.

On the other hand I don't see any reason not to support session based subscriptions either.

regards Balazs

Juergen Schoenwaelder wrote:
> 
> What I am interested in is to have an easy mechanism to request that
> notifications are directed to a given session (by default 'this'
> session if we allow mixed content) and to have that request bound to
> the lifetime of the session. In other words, I am thinking of a
> subscription which establishes operational state rather than a change
> of the configuration of the device and hence <edit-config> might not
> be the primitive of choice.
> 
> You are looking for ways to configure persistent notificiation
> receivers and I agree that this is essentially a configuration change
> and so <edit-config> seems to be the appropriate primitive to use.
> 
> I think the first decision to take is whether the WG wants to support
> both, one, or none of the use cases.
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com



--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 05 12:21:26 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fc33W-0007zw-MC
	for netconf-archive@lists.ietf.org; Fri, 05 May 2006 12:21:26 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fc32j-0002JS-R2
	for netconf-archive@lists.ietf.org; Fri, 05 May 2006 12:20:41 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fc2xn-000BuD-SJ
	for netconf-data@psg.com; Fri, 05 May 2006 16:15:31 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fc2xn-000Bu1-8A
	for netconf@ops.ietf.org; Fri, 05 May 2006 16:15:31 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.hosting.dc2.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k45GFUDA011139
	for <netconf@ops.ietf.org>; Fri, 5 May 2006 12:15:30 -0400
Received: (qmail 11269 invoked by uid 78); 5 May 2006 16:15:30 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 5 May 2006 16:15:30 -0000
Message-ID: <445B7A1C.9090803@andybierman.com>
Date: Fri, 05 May 2006 09:15:24 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: event classes (sec. 3.5)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d

Hi,

This section is very under-specified.

IMO, it is impossible for independent developers
to select classifications in an interoperable manner.

It is really not at all clear why we need audit, data,
maintenance, metrics, information, and syslog classes at all.

Most of these are totally redundant.

Metrics is out of scope.

Syslog is not a proper member of this classification set.
In XML, we use namespaces to identify content format,
such as syslog/RAW, syslog/COOKED, acme/TOASTED, etc.
The notification <data> section will be just like
the <config> or <data> elements already defined in
the protocol.

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 05 16:40:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fc763-0005ZY-1r
	for netconf-archive@lists.ietf.org; Fri, 05 May 2006 16:40:19 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fc760-0000cs-OR
	for netconf-archive@lists.ietf.org; Fri, 05 May 2006 16:40:19 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fc6yL-00034l-LJ
	for netconf-data@psg.com; Fri, 05 May 2006 20:32:21 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fc6yK-00034U-NQ
	for netconf@ops.ietf.org; Fri, 05 May 2006 20:32:21 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.hosting.dc2.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k45KWJ4c025379
	for <netconf@ops.ietf.org>; Fri, 5 May 2006 16:32:19 -0400
Received: (qmail 31016 invoked by uid 78); 5 May 2006 20:32:19 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 5 May 2006 20:32:19 -0000
Message-ID: <445BB64D.3000408@andybierman.com>
Date: Fri, 05 May 2006 13:32:13 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: interim meeting update
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a

Hi,

The NETCONF WG interim meeting will be held in Montreal
on July 14th and 15th.  The meeting location will be
the IETF Hotel (Delta Centre-Ville).

We are still looking for sponsors to help pay for the
meeting. So far, tail-f and I are splitting
the bill.  Hopefully some big companies can pitch in as well.
(I think we still need to borrow a projector for powerpoint.)

I would like to get a headcount of people who plan
to attend the interim meeting, so we can finalize
the room size and catering order.

Can people send me private email (or to the list if you want)
RSVPing for this meeting?  We will have the regular WG
meeting on Friday 7/14 from 9 - 11:30 at the conference
center, then start the interim at 1:30 at the hotel.
Saturday we will meet from 9am to 6pm with 2 breaks.


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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Sat May 06 13:58:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FcR3M-0002op-NO
	for netconf-archive@lists.ietf.org; Sat, 06 May 2006 13:58:52 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FcR3M-00022U-C9
	for netconf-archive@lists.ietf.org; Sat, 06 May 2006 13:58:52 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FcQxl-000HIs-Oz
	for netconf-data@psg.com; Sat, 06 May 2006 17:53:05 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FcCzC-0000v4-GL
	for netconf@ops.ietf.org; Sat, 06 May 2006 02:57:38 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.hosting.dc2.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k462vb99009844
	for <netconf@ops.ietf.org>; Fri, 5 May 2006 22:57:37 -0400
Received: (qmail 10004 invoked by uid 78); 6 May 2006 02:57:37 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 6 May 2006 02:57:37 -0000
Message-ID: <445C109B.5030802@andybierman.com>
Date: Fri, 05 May 2006 19:57:31 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: comments on draft-ietf-netconf-notification-01.txt
References: <6E21698722408147BEA594E073E2B0AB01CA0793@xmb-sjc-223.amer.cisco.com> <4458DDE9.8030506@andybierman.com> <20060503190301.GA8800@boskop.local> <445906BB.2010305@andybierman.com> <20060503201320.GF8800@boskop.local> <44592133.3050302@andybierman.com> <20060504102501.GA10929@boskop.local> <4459DBD4.8080302@ericsson.com>
In-Reply-To: <4459DBD4.8080302@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4

Balazs Lengyel wrote:
> In the current draft even short lived subscriptions (session based) can 
> be queried (Section 3.2) so to me they seem to be data.
> 
> In Ericsson we need  persistent receivers. Imagine a management station 
> that manages 5000  nodes. When the management station restarts it does 
> not want to go and subscribe 5000 times if this can be avoided.
> 

I agree.
I thought about this problem and punted (in my latest data
model email proposal).

The entire callhome feature needs to be independently specified
in full detail, for all 3 transports (if possible).  There are security
considerations, reason-for-connect, redundancy and failover,
capabilities format, and many other details to work out.
I think Eliot Lear is working with someone at Cisco on this problem.
It didn't just fall through the cracks.


> On the other hand I don't see any reason not to support session based 
> subscriptions either.


I agree.
Let's make sure the agent reuses as much code as possible.
Notice I haven't complained about all the filtering the
agent has to do for a subscription?  The agent already
needs to have that code for <get-config> and <get>, so
this is total code reuse -- an excellent way to do filtering.



> 
> regards Balazs


Andy

> 
> Juergen Schoenwaelder wrote:
>>
>> What I am interested in is to have an easy mechanism to request that
>> notifications are directed to a given session (by default 'this'
>> session if we allow mixed content) and to have that request bound to
>> the lifetime of the session. In other words, I am thinking of a
>> subscription which establishes operational state rather than a change
>> of the configuration of the device and hence <edit-config> might not
>> be the primitive of choice.
>>
>> You are looking for ways to configure persistent notificiation
>> receivers and I agree that this is essentially a configuration change
>> and so <edit-config> seems to be the appropriate primitive to use.
>>
>> I think the first decision to take is whether the WG wants to support
>> both, one, or none of the use cases.
>>
> 




--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Sat May 06 18:15:18 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FcV3W-0003Qn-M2
	for netconf-archive@lists.ietf.org; Sat, 06 May 2006 18:15:18 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FcV3U-0005Fe-8d
	for netconf-archive@lists.ietf.org; Sat, 06 May 2006 18:15:18 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FcUyD-000DdY-UD
	for netconf-data@psg.com; Sat, 06 May 2006 22:09:49 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FcUyC-000Dd0-BH
	for netconf@ops.ietf.org; Sat, 06 May 2006 22:09:48 +0000
Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id D6F393D
	for <netconf@ops.ietf.org>; Sun,  7 May 2006 00:09:46 +0200 (CEST)
Date: Sun, 07 May 2006 00:09:37 +0200 (CEST)
Message-Id: <20060507.000937.69981240.mbj@tail-f.com>
To: netconf@ops.ietf.org
Subject: subtree filtering question
From: Martin Bjorklund <mbj@tail-f.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36

Hi,

While reading the subtree filtering specs again, I found something
which is a bit unclear.

Consider this example from the draft.

     <filter type="subtree">
       <top xmlns="http://example.com/schema/1.2/config">
         <users>
           <user>
             <name>fred</name>
           </user>
         </users>
       </top>
     </filter>

The question is what is the result if no user 'fred' exists?

Is it (1):

     <data>
     </data>

or (2):

     <data>
       <top xmlns="http://example.com/schema/1.2/config">
         <users>
         </users>
       </top>
     </data>   

or maybe (3):

     <data>
       <top xmlns="http://example.com/schema/1.2/config">
         <users>
           <user>
           </user>
         </users>
       </top>
     </data>   

Section 6.2.3 on containment node says:

   For each containment node specified in a subtree filter, all data
   model instances which exactly match the specified namespaces,
   element hierarchy, and any attribute match expressions are included
   in the filter output.

which seems to imply that alternative 3 is the right choice.  But in
section 6.3. it says:

   If the entire subtree data-fragment filter (starting from the root
   to the innermost element specified in the filter) exactly matches a
   corresponding portion of the supported data model, then that node
   and all its children are included in the result data.

Which seems to indicate that alternative 1 is right.  This might also
be implied by the text on content match nodes:

   o  If any containment nodes are present in the sibling set then they
      are processed further, and included if any nested filter criteria
      are also met.

(although this only seems to apply to containment nodes which are
siblings to content match nodes)


/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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 11 13:39:03 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FeF7v-00078c-6h
	for netconf-archive@lists.ietf.org; Thu, 11 May 2006 13:39:03 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FeF7s-0004NZ-Nj
	for netconf-archive@lists.ietf.org; Thu, 11 May 2006 13:39:03 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FeF2E-0007uI-8j
	for netconf-data@psg.com; Thu, 11 May 2006 17:33:10 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS autolearn=no version=3.1.1
Received: from [216.148.227.154] (helo=rwcrmhc14.comcast.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <dbharrington@comcast.net>)
	id 1FeF2D-0007u5-BB
	for netconf@ops.ietf.org; Thu, 11 May 2006 17:33:09 +0000
Received: from harrington73653 (c-24-128-66-70.hsd1.nh.comcast.net[24.128.66.70])
          by comcast.net (rwcrmhc14) with SMTP
          id <20060511173307m1400ki7jje>; Thu, 11 May 2006 17:33:08 +0000
From: "David B Harrington" <dbharrington@comcast.net>
To: "'Balazs Lengyel'" <balazs.lengyel@ericsson.com>,
	"'Netconf \(E-mail\)'" <netconf@ops.ietf.org>
Subject: RE: manager subscription model for notifications: usage survey
Date: Thu, 11 May 2006 13:32:22 -0400
Message-ID: <02d801c67520$dcfcb4f0$0400a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <445705B1.2090006@ericsson.com>
Importance: Normal
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8

Hi,

At Enterasys, which focused on enterprise networks, we had a customer
managing an 88000 node network with our snmp application. The size of
managed networks is growing rapidly, so let's not constrain the
network size too much (but let's not go add lots of features only
useful in huge networks either).

Understand that some of the devices being managed were fairly simple
things like vending machines, not complex things like routers, but it
will be a good thing if devices other than routers can be used with
netconf.

dbh

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel
> Sent: Tuesday, May 02, 2006 3:10 AM
> To: Netconf (E-mail)
> Subject: Re: manager subscription model for notifications: 
> usage survey
> 
> 
> Andy mentions 100-1000 devices. In Ericsson we have systems 
> supervising up to 30000 
> devices. So we should aim somewhat higher with scalability. 
> (Today these use other 
> protocols, but they are a candidate for Netconf.)
> Balazs
> 
> Andy Bierman wrote:
> > Hi,
> > 
> > I am having a hard time understanding how the
> > peer-to-peer manager subscribe model defined
> > in the notifications draft fits with syslog and
> > SNMP notifications already in use.
> > 
> > 
> > I think it would be wise to understand how the entire
> > managed system is going to work when netconf notifications
> > are added to the mix.   How will a network of 100 - 10000 devics
> > behave in various common failure scenarios?
> > 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 11 15:12:02 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FeGZu-0003tC-PG
	for netconf-archive@lists.ietf.org; Thu, 11 May 2006 15:12:02 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FeGZp-0000DS-DL
	for netconf-archive@lists.ietf.org; Thu, 11 May 2006 15:12:02 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FeGVr-000Dvd-7S
	for netconf-data@psg.com; Thu, 11 May 2006 19:07:51 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FeGVo-000DvM-Ap
	for netconf@ops.ietf.org; Thu, 11 May 2006 19:07:48 +0000
Received: from mail.networksolutionsemail.com (ns-omr2.mgt.hosting.dc2.netsol.com [10.49.6.65])
	by ns-omrbm2.netsolmail.com (8.13.6/8.13.6) with SMTP id k4BJ7lNv026461
	for <netconf@ops.ietf.org>; Thu, 11 May 2006 15:07:47 -0400
Received: (qmail 15669 invoked by uid 78); 11 May 2006 19:07:47 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 11 May 2006 19:07:47 -0000
Message-ID: <44638BCD.2020203@andybierman.com>
Date: Thu, 11 May 2006 12:09:01 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: David B Harrington <dbharrington@comcast.net>
CC: "'Balazs Lengyel'" <balazs.lengyel@ericsson.com>,
        "'Netconf (E-mail)'" <netconf@ops.ietf.org>
Subject: Re: manager subscription model for notifications: usage survey
References: <02d801c67520$dcfcb4f0$0400a8c0@china.huawei.com>
In-Reply-To: <02d801c67520$dcfcb4f0$0400a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69

David B Harrington wrote:
> Hi,
> 
> At Enterasys, which focused on enterprise networks, we had a customer
> managing an 88000 node network with our snmp application. The size of
> managed networks is growing rapidly, so let's not constrain the
> network size too much (but let's not go add lots of features only
> useful in huge networks either).

Not sure what this comment means, other than the current
manager-subscribe proposal scales even worse than I claimed.
So let's target 100000 devices, not 10000.  So imagine
one or more managers starting 100000 sessions, and issuing
100000 RPCs, just to get notifications restarted after manager
connectivity is lost.

Seems to me that session-based notifications are really expensive,
and don't scale well, even if the agent initiates the session.
Maybe that's why syslog and SNMP don't use sessions.  Hmmm...
At best, this netconf notification feature is a way to receive copies
of notifications in a session, while connected for operations.
Not sure why that is important, but it is not related to,
and not going to replace, syslog/SNMP notifications.


> 
> Understand that some of the devices being managed were fairly simple
> things like vending machines, not complex things like routers, but it
> will be a good thing if devices other than routers can be used with
> netconf.

agreed.
The KISS Factor (keep it simple stupid) applies here.
Is this thing we are building an embedded agent or a mid-level manager?
It looks like the latter to me.

> 
> dbh

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 11 15:34:08 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FeGvI-0001xY-N2
	for netconf-archive@lists.ietf.org; Thu, 11 May 2006 15:34:08 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FeGvG-0001Se-9j
	for netconf-archive@lists.ietf.org; Thu, 11 May 2006 15:34:08 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FeGsE-000FOj-W5
	for netconf-data@psg.com; Thu, 11 May 2006 19:30:58 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FeGsD-000FOU-Of
	for netconf@ops.ietf.org; Thu, 11 May 2006 19:30:57 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id AAD8D55E74;
	Thu, 11 May 2006 21:30:56 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 30987-06; Thu, 11 May 2006 21:30:54 +0200 (CEST)
Received: from boskop.local (unknown [10.222.1.3])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id 2DA4355F89;
	Thu, 11 May 2006 21:30:54 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id 3C2F86D78AE; Thu, 11 May 2006 21:29:51 +0200 (CEST)
Date: Thu, 11 May 2006 21:29:51 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: David B Harrington <dbharrington@comcast.net>
Cc: "'Netconf (E-mail)'" <netconf@ops.ietf.org>
Subject: Re: manager subscription model for notifications: usage survey
Message-ID: <20060511192951.GD2138@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: David B Harrington <dbharrington@comcast.net>,
	"'Netconf (E-mail)'" <netconf@ops.ietf.org>
References: <445705B1.2090006@ericsson.com> <02d801c67520$dcfcb4f0$0400a8c0@china.huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <02d801c67520$dcfcb4f0$0400a8c0@china.huawei.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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab

On Thu, May 11, 2006 at 01:32:22PM -0400, David B Harrington wrote:
 
> At Enterasys, which focused on enterprise networks, we had a customer
> managing an 88000 node network with our snmp application. The size of
> managed networks is growing rapidly, so let's not constrain the
> network size too much (but let's not go add lots of features only
> useful in huge networks either).

Before I am getting impressed, I would love to know what "managing"
means, e.g. what the traffic exchanges between the 88000 nodes and the
single system(?) central manager are.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 11 16:22:51 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FeHgR-0006HR-Se
	for netconf-archive@lists.ietf.org; Thu, 11 May 2006 16:22:51 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FeHgQ-0003v5-6k
	for netconf-archive@lists.ietf.org; Thu, 11 May 2006 16:22:51 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FeHcf-000IKZ-9K
	for netconf-data@psg.com; Thu, 11 May 2006 20:18:57 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FeHcd-000IKH-Uw
	for netconf@ops.ietf.org; Thu, 11 May 2006 20:18:56 +0000
Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id 4940E47
	for <netconf@ops.ietf.org>; Thu, 11 May 2006 22:18:54 +0200 (CEST)
Date: Thu, 11 May 2006 22:18:44 +0200 (CEST)
Message-Id: <20060511.221844.109344212.mbj@tail-f.com>
To: netconf@ops.ietf.org
Subject: Re: subtree filtering question
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20060507.000937.69981240.mbj@tail-f.com>
References: <20060507.000937.69981240.mbj@tail-f.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86

Hi again.

Actually, I think that - from reading the specs - the answer is
alternative 3.

If this is the correct answer, the follow-up question is how subtree
filtering is supposed to be used to match a notification.  With XPath,
it is defined that an expression which results in an empty node set is
interpreted as 'false', and a non-empty node set is interpreted as
'true'.  If the same rule is applies to subtree filtering, a filter
such as that shown below (which produces a non-empty node set even for
a "no match") would be interpreted as true.


/martin



Martin Bjorklund <mbj@tail-f.com> wrote:
> Hi,
> 
> While reading the subtree filtering specs again, I found something
> which is a bit unclear.
> 
> Consider this example from the draft.
> 
>      <filter type="subtree">
>        <top xmlns="http://example.com/schema/1.2/config">
>          <users>
>            <user>
>              <name>fred</name>
>            </user>
>          </users>
>        </top>
>      </filter>
> 
> The question is what is the result if no user 'fred' exists?
> 
> Is it (1):
> 
>      <data>
>      </data>
> 
> or (2):
> 
>      <data>
>        <top xmlns="http://example.com/schema/1.2/config">
>          <users>
>          </users>
>        </top>
>      </data>   
> 
> or maybe (3):
> 
>      <data>
>        <top xmlns="http://example.com/schema/1.2/config">
>          <users>
>            <user>
>            </user>
>          </users>
>        </top>
>      </data>   
> 
> Section 6.2.3 on containment node says:
> 
>    For each containment node specified in a subtree filter, all data
>    model instances which exactly match the specified namespaces,
>    element hierarchy, and any attribute match expressions are included
>    in the filter output.
> 
> which seems to imply that alternative 3 is the right choice.  But in
> section 6.3. it says:
> 
>    If the entire subtree data-fragment filter (starting from the root
>    to the innermost element specified in the filter) exactly matches a
>    corresponding portion of the supported data model, then that node
>    and all its children are included in the result data.
> 
> Which seems to indicate that alternative 1 is right.  This might also
> be implied by the text on content match nodes:
> 
>    o  If any containment nodes are present in the sibling set then they
>       are processed further, and included if any nested filter criteria
>       are also met.
> 
> (although this only seems to apply to containment nodes which are
> siblings to content match nodes)
> 
> 
> /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: <http://ops.ietf.org/lists/netconf/>

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 11 17:11:18 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FeIRJ-00016C-VQ
	for netconf-archive@lists.ietf.org; Thu, 11 May 2006 17:11:17 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FeIRH-0006iW-Fp
	for netconf-archive@lists.ietf.org; Thu, 11 May 2006 17:11:17 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FeINe-000Lb9-Sc
	for netconf-data@psg.com; Thu, 11 May 2006 21:07:30 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FeINe-000Law-1F
	for netconf@ops.ietf.org; Thu, 11 May 2006 21:07:30 +0000
Received: from mail.networksolutionsemail.com (ns-omr6.mgt.hosting.dc2.netsol.com [10.49.6.69])
	by ns-omrbm6.netsolmail.com (8.13.6/8.13.6) with SMTP id k4BL7RIU005909
	for <netconf@ops.ietf.org>; Thu, 11 May 2006 17:07:29 -0400
Received: (qmail 25385 invoked by uid 78); 11 May 2006 21:07:26 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.69 with SMTP; 11 May 2006 21:07:26 -0000
Message-ID: <4463A7EB.9010307@andybierman.com>
Date: Thu, 11 May 2006 14:08:59 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC: netconf@ops.ietf.org
Subject: Re: subtree filtering question
References: <20060507.000937.69981240.mbj@tail-f.com> <20060511.221844.109344212.mbj@tail-f.com>
In-Reply-To: <20060511.221844.109344212.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c

Martin Bjorklund wrote:
> Hi again.
> 
> Actually, I think that - from reading the specs - the answer is
> alternative 3.
> 
> If this is the correct answer, the follow-up question is how subtree
> filtering is supposed to be used to match a notification.  With XPath,
> it is defined that an expression which results in an empty node set is
> interpreted as 'false', and a non-empty node set is interpreted as
> 'true'.  If the same rule is applies to subtree filtering, a filter
> such as that shown below (which produces a non-empty node set even for
> a "no match") would be interpreted as true.


You are correct.
I sure do not like it, but you are correct.
The same conceptual netconf filter in xpath and subtree form
will not return the same output. That is awful.

I remember this issue came up, and the notion of removing the
entire 'dead-end' subtree from the result (back to the root)
was discussed.  That was the original intent.

The current text seems to indicate that (2) should be returned
if the <users> container is totally empty, and (3) if
it is not empty, but the requested entry 'fred' does not exist.

In either case, this is not very useful as-is for
notification filtering. Not so great for <get> filtering either.


> 
> 
> /martin

Andy


> 
> 
> 
> Martin Bjorklund <mbj@tail-f.com> wrote:
>> Hi,
>>
>> While reading the subtree filtering specs again, I found something
>> which is a bit unclear.
>>
>> Consider this example from the draft.
>>
>>      <filter type="subtree">
>>        <top xmlns="http://example.com/schema/1.2/config">
>>          <users>
>>            <user>
>>              <name>fred</name>
>>            </user>
>>          </users>
>>        </top>
>>      </filter>
>>
>> The question is what is the result if no user 'fred' exists?
>>
>> Is it (1):
>>
>>      <data>
>>      </data>
>>
>> or (2):
>>
>>      <data>
>>        <top xmlns="http://example.com/schema/1.2/config">
>>          <users>
>>          </users>
>>        </top>
>>      </data>   
>>
>> or maybe (3):
>>
>>      <data>
>>        <top xmlns="http://example.com/schema/1.2/config">
>>          <users>
>>            <user>
>>            </user>
>>          </users>
>>        </top>
>>      </data>   
>>
>> Section 6.2.3 on containment node says:
>>
>>    For each containment node specified in a subtree filter, all data
>>    model instances which exactly match the specified namespaces,
>>    element hierarchy, and any attribute match expressions are included
>>    in the filter output.
>>
>> which seems to imply that alternative 3 is the right choice.  But in
>> section 6.3. it says:
>>
>>    If the entire subtree data-fragment filter (starting from the root
>>    to the innermost element specified in the filter) exactly matches a
>>    corresponding portion of the supported data model, then that node
>>    and all its children are included in the result data.
>>
>> Which seems to indicate that alternative 1 is right.  This might also
>> be implied by the text on content match nodes:
>>
>>    o  If any containment nodes are present in the sibling set then they
>>       are processed further, and included if any nested filter criteria
>>       are also met.
>>
>> (although this only seems to apply to containment nodes which are
>> siblings to content match nodes)
>>
>>
>> /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: <http://ops.ietf.org/lists/netconf/>
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 11 17:12:39 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FeISd-0002Jb-32
	for netconf-archive@lists.ietf.org; Thu, 11 May 2006 17:12:39 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FeISa-0006mg-Lp
	for netconf-archive@lists.ietf.org; Thu, 11 May 2006 17:12:39 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FeIQI-000LtL-3Q
	for netconf-data@psg.com; Thu, 11 May 2006 21:10:14 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS autolearn=no version=3.1.1
Received: from [204.127.192.84] (helo=rwcrmhc14.comcast.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <dbharrington@comcast.net>)
	id 1FeIQH-000Lt6-18
	for netconf@ops.ietf.org; Thu, 11 May 2006 21:10:13 +0000
Received: from harrington73653 (c-24-128-66-70.hsd1.nh.comcast.net[24.128.66.70])
          by comcast.net (rwcrmhc14) with SMTP
          id <20060511211006m1400knfg7e>; Thu, 11 May 2006 21:10:12 +0000
From: "David B Harrington" <dbharrington@comcast.net>
To: <j.schoenwaelder@iu-bremen.de>
Cc: "'Netconf \(E-mail\)'" <netconf@ops.ietf.org>
Subject: RE: manager subscription model for notifications: usage survey
Date: Thu, 11 May 2006 17:09:21 -0400
Message-ID: <033601c6753f$2fcb2630$0400a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <20060511192951.GD2138@boskop.local>
Importance: Normal
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c

Hi,

Not trying to impress, just pointing out the need for scalability to
more than 10k or 30k devices, and the need to keep things simple.

The management was very simple as far as I know. It was an academic
campus. Management included initial configuration for things like "who
should I talk to?" and notifications when items in the vending
machines ran low. This saved a lot of "polling" by humans having to go
to the physical machines. I'm not sure how much other management was
done.

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20
> Sent: Thursday, May 11, 2006 3:30 PM
> To: David B Harrington
> Cc: 'Netconf (E-mail)'
> Subject: Re: manager subscription model for notifications:=20
> usage survey
>=20
>=20
> On Thu, May 11, 2006 at 01:32:22PM -0400, David B Harrington wrote:
> =20
> > At Enterasys, which focused on enterprise networks, we had=20
> a customer
> > managing an 88000 node network with our snmp application.=20
> The size of
> > managed networks is growing rapidly, so let's not constrain the
> > network size too much (but let's not go add lots of features only
> > useful in huge networks either).
>=20
> Before I am getting impressed, I would love to know what "managing"
> means, e.g. what the traffic exchanges between the 88000 nodes and
the
> single system(?) central manager are.
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 11 17:23:27 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FeId5-0002gA-8u
	for netconf-archive@lists.ietf.org; Thu, 11 May 2006 17:23:27 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FeId2-00071X-MS
	for netconf-archive@lists.ietf.org; Thu, 11 May 2006 17:23:27 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FeIZP-000MaJ-W6
	for netconf-data@psg.com; Thu, 11 May 2006 21:19:39 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FeIZO-000Ma8-5m
	for netconf@ops.ietf.org; Thu, 11 May 2006 21:19:38 +0000
Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id 50B0C48;
	Thu, 11 May 2006 23:19:37 +0200 (CEST)
Date: Thu, 11 May 2006 23:19:27 +0200 (CEST)
Message-Id: <20060511.231927.126912941.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: netconf@ops.ietf.org
Subject: Re: subtree filtering question
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4463A7EB.9010307@andybierman.com>
References: <20060507.000937.69981240.mbj@tail-f.com>
	<20060511.221844.109344212.mbj@tail-f.com>
	<4463A7EB.9010307@andybierman.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f

Andy Bierman <ietf@andybierman.com> wrote:
> Martin Bjorklund wrote:
> > Hi again.
> > 
> > Actually, I think that - from reading the specs - the answer is
> > alternative 3.
> > 
> > If this is the correct answer, the follow-up question is how subtree
> > filtering is supposed to be used to match a notification.  With XPath,
> > it is defined that an expression which results in an empty node set is
> > interpreted as 'false', and a non-empty node set is interpreted as
> > 'true'.  If the same rule is applies to subtree filtering, a filter
> > such as that shown below (which produces a non-empty node set even for
> > a "no match") would be interpreted as true.
> 
> 
> You are correct.
> I sure do not like it, but you are correct.
> The same conceptual netconf filter in xpath and subtree form
> will not return the same output. That is awful.
> 
> I remember this issue came up, and the notion of removing the
> entire 'dead-end' subtree from the result (back to the root)
> was discussed.  That was the original intent.
> 
> The current text seems to indicate that (2) should be returned
> if the <users> container is totally empty, and (3) if
> it is not empty, but the requested entry 'fred' does not exist.
> 
> In either case, this is not very useful as-is for
> notification filtering. Not so great for <get> filtering either.

Well, the good thing about it is (as I think was the intent) that it's
simple to implement (for get-filtering), since the code always can
make a local decision.  And altough I haven't actually implemented a
manager, I don't think the result is difficult to interpret.

For notification filtering it's worse than not very useful, unless
someone can come up with a scheme to interpret the outcome of the
subtree filter so that it means what it's supposed to mean...


/martin



> 
> 
> > 
> > 
> > /martin
> 
> Andy
> 
> 
> > 
> > 
> > 
> > Martin Bjorklund <mbj@tail-f.com> wrote:
> >> Hi,
> >>
> >> While reading the subtree filtering specs again, I found something
> >> which is a bit unclear.
> >>
> >> Consider this example from the draft.
> >>
> >>      <filter type="subtree">
> >>        <top xmlns="http://example.com/schema/1.2/config">
> >>          <users>
> >>            <user>
> >>              <name>fred</name>
> >>            </user>
> >>          </users>
> >>        </top>
> >>      </filter>
> >>
> >> The question is what is the result if no user 'fred' exists?
> >>
> >> Is it (1):
> >>
> >>      <data>
> >>      </data>
> >>
> >> or (2):
> >>
> >>      <data>
> >>        <top xmlns="http://example.com/schema/1.2/config">
> >>          <users>
> >>          </users>
> >>        </top>
> >>      </data>   
> >>
> >> or maybe (3):
> >>
> >>      <data>
> >>        <top xmlns="http://example.com/schema/1.2/config">
> >>          <users>
> >>            <user>
> >>            </user>
> >>          </users>
> >>        </top>
> >>      </data>   
> >>
> >> Section 6.2.3 on containment node says:
> >>
> >>    For each containment node specified in a subtree filter, all data
> >>    model instances which exactly match the specified namespaces,
> >>    element hierarchy, and any attribute match expressions are included
> >>    in the filter output.
> >>
> >> which seems to imply that alternative 3 is the right choice.  But in
> >> section 6.3. it says:
> >>
> >>    If the entire subtree data-fragment filter (starting from the root
> >>    to the innermost element specified in the filter) exactly matches a
> >>    corresponding portion of the supported data model, then that node
> >>    and all its children are included in the result data.
> >>
> >> Which seems to indicate that alternative 1 is right.  This might also
> >> be implied by the text on content match nodes:
> >>
> >>    o  If any containment nodes are present in the sibling set then they
> >>       are processed further, and included if any nested filter criteria
> >>       are also met.
> >>
> >> (although this only seems to apply to containment nodes which are
> >> siblings to content match nodes)
> >>
> >>
> >> /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: <http://ops.ietf.org/lists/netconf/>
> > 
> > --
> > to unsubscribe send a message to netconf-request@ops.ietf.org with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://ops.ietf.org/lists/netconf/>
> > 
> > 
> 

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 11 17:47:33 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FeJ0P-0002vX-NK
	for netconf-archive@lists.ietf.org; Thu, 11 May 2006 17:47:33 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FeJ0N-0007uJ-De
	for netconf-archive@lists.ietf.org; Thu, 11 May 2006 17:47:33 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FeItt-000O34-BN
	for netconf-data@psg.com; Thu, 11 May 2006 21:40:49 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FeIts-000O2s-I1
	for netconf@ops.ietf.org; Thu, 11 May 2006 21:40:48 +0000
Received: from mail.networksolutionsemail.com (ns-omr3.mgt.hosting.dc2.netsol.com [10.49.6.66])
	by ns-omrbm3.netsolmail.com (8.13.6/8.13.6) with SMTP id k4BLeli3025901
	for <netconf@ops.ietf.org>; Thu, 11 May 2006 17:40:47 -0400
Received: (qmail 25042 invoked by uid 78); 11 May 2006 21:40:47 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.66 with SMTP; 11 May 2006 21:40:47 -0000
Message-ID: <4463AFC0.1030502@andybierman.com>
Date: Thu, 11 May 2006 14:42:24 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: David B Harrington <dbharrington@comcast.net>
CC: j.schoenwaelder@iu-bremen.de, "'Netconf (E-mail)'" <netconf@ops.ietf.org>
Subject: Re: manager subscription model for notifications: usage survey
References: <033601c6753f$2fcb2630$0400a8c0@china.huawei.com>
In-Reply-To: <033601c6753f$2fcb2630$0400a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2

David B Harrington wrote:
> Hi,
> 
> Not trying to impress, just pointing out the need for scalability to
> more than 10k or 30k devices, and the need to keep things simple.
> 
> The management was very simple as far as I know. It was an academic
> campus. Management included initial configuration for things like "who
> should I talk to?" and notifications when items in the vending
> machines ran low. This saved a lot of "polling" by humans having to go
> to the physical machines. I'm not sure how much other management was
> done.

Not sure if 'scalability' and 'simplicity' are in
the requirements list.

So do you think the current draft meets these requirements?
If not, then any suggested changes would also be helpful.

We need to move from an abstract discussion to a review
of the current draft.


> 
> dbh


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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 11 18:07:37 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FeJJp-0005Lt-50
	for netconf-archive@lists.ietf.org; Thu, 11 May 2006 18:07:37 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FeJJm-0000M2-Qg
	for netconf-archive@lists.ietf.org; Thu, 11 May 2006 18:07:37 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FeJGR-000PVo-B9
	for netconf-data@psg.com; Thu, 11 May 2006 22:04:07 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FeJGQ-000PVc-8h
	for netconf@ops.ietf.org; Thu, 11 May 2006 22:04:06 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 875E95605B;
	Fri, 12 May 2006 00:04:05 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP
 id 11193-02; Fri, 12 May 2006 00:04:03 +0200 (CEST)
Received: from boskop.local (unknown [10.222.1.3])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id A28E756049;
	Fri, 12 May 2006 00:04:03 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id 7DED96D7B05; Fri, 12 May 2006 00:04:01 +0200 (CEST)
Date: Fri, 12 May 2006 00:04:01 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: David B Harrington <dbharrington@comcast.net>
Cc: "'Netconf (E-mail)'" <netconf@ops.ietf.org>
Subject: Re: manager subscription model for notifications: usage survey
Message-ID: <20060511220401.GA2933@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: David B Harrington <dbharrington@comcast.net>,
	"'Netconf (E-mail)'" <netconf@ops.ietf.org>
References: <20060511192951.GD2138@boskop.local> <033601c6753f$2fcb2630$0400a8c0@china.huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <033601c6753f$2fcb2630$0400a8c0@china.huawei.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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126

On Thu, May 11, 2006 at 05:09:21PM -0400, David B Harrington wrote:
 
> Not trying to impress, just pointing out the need for scalability to
> more than 10k or 30k devices, and the need to keep things simple.

The number of devices is simply irrelevant as long as we do not also
state the traffic pattern. And as Andy said, I doubt that NetConf's
primary goal is highly scalable notification delivery.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 12 08:45:44 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FeX1c-0002Vb-7M
	for netconf-archive@lists.ietf.org; Fri, 12 May 2006 08:45:44 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FeX1a-0001Cs-TY
	for netconf-archive@lists.ietf.org; Fri, 12 May 2006 08:45:44 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FeWv3-000O43-92
	for netconf-data@psg.com; Fri, 12 May 2006 12:38:57 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FeWv2-000O3r-2Q
	for netconf@ops.ietf.org; Fri, 12 May 2006 12:38:56 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4CCcqk02208
	for <netconf@ops.ietf.org>; Fri, 12 May 2006 08:38:52 -0400 (EDT)
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: Verbiage
Date: Fri, 12 May 2006 08:38:51 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4086CC012@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Verbiage
Thread-Index: AcZ1wQXY5NTaXTZmQMG4u3KC3DVuLg==
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15

hi

I've just read through the very interesting discussion on use of verbs.
I would have joined in but I had this cold which brought me down a few
million IQ points, so I figured it would be safer to wait.

It seems there does seem to interest in having specialized verbs for
subscriptions. I think talking about subscriptions as 'operational
state' as appose to 'configuration data' was a great bit of
clarification. I also thought the discussion about moving from low level
programming languages (peek and pokes) to more procedural was also a
good analogy.

I think we need to find a comfortable place between the two extremes of
get/set and having a verb for every possible action on the box. Note
that we already created 'specialized' verbs in the base protocol - we
have get and get-config for example. We have been having to make these
decisions within product and I don't think we have reached a really
prescriptive criteria of when to create new verbs, I think the two big
questions are
	- Is it possible to do it in the datamodel without exploiting
side-effects?
	- Is the verb management related (reboot-box as appose to
create-atm-interface, for example).


As has been suggested, verbs, if there are not too many of them, make it
much easer for operators and management applications to figure out what
they need to do achieve their goal. It has been suggested that
operations on the datamodel would be easer for the agent-side to
develop. While I imagine that is true for the netconf stack, I think
that is ignoring the rest of the network element. Once the command has
been received by the agent, it them gets passed onto routines that do
the real work. In my experience, these real routines are not doing
peek/poke operations either. The network element must re-assemble the
command from the collection of things that have been provided in the
data model and realize that the user is trying to create a subscription.

Pushing things to the datamodel starts to look like


I'd like to subscribe ->  <edit-config> <data/> </edit-config> ->  =20

					|
					V

-> </edit-config> <data/> </edit-config> -> is this valid edit-config ->
Oh, they would like to subscribe -> is it a valid subscription -> ok,
I'll subscribe them then

And in this case, is it possible for the edit-config to be valid, but
have errors that prevent the subscription from being created?

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 12 08:50:16 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FeX60-0004ph-Ec
	for netconf-archive@lists.ietf.org; Fri, 12 May 2006 08:50:16 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FeX5y-0001Sa-2E
	for netconf-archive@lists.ietf.org; Fri, 12 May 2006 08:50:16 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FeX18-000OSf-Kz
	for netconf-data@psg.com; Fri, 12 May 2006 12:45:14 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.129.242.56] (helo=zcars04e.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FeX17-000OSP-RJ
	for netconf@ops.ietf.org; Fri, 12 May 2006 12:45:14 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k4CCeF229230
	for <netconf@ops.ietf.org>; Fri, 12 May 2006 08:40:15 -0400 (EDT)
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: The datamodel in Notification Draft
Date: Fri, 12 May 2006 08:45:10 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4086CC037@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: The datamodel in Notification Draft
Thread-Index: AcZ1weemEJA/wTCkRwOYh++WcD1MvA==
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034

hi

A few bits of clarification after reading through the discussions.

1. Named profiles in the latest version of the draft are fully specified
in the XML Schema provided. This allows for persistency of subscription
information, just not the actual subscription. The callHome capability
does allow for this persistency though.

2. The information model that Andy sent out didn't seem that different
from what is in the draft already. I believe these were the differences
	- It wasn't specified in XML Schema
	- It used the term table as appose to elements
      - It had an arbitrary index instead of using sessionId and
subscriptionID
	- It better specified the subscriber. As Balasz pointed out, the
current draft if not sufficiently prescriptive. Subscriber is only a
string.

3. I think it would be good if we could look at defining minAccess and
maxAccess in a machine-readable form to publish in parallel with this
document. Failing that, I guess we have no choice but to fall back using
the documentation tag.


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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 12 08:54:25 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FeXA1-00065h-6O
	for netconf-archive@lists.ietf.org; Fri, 12 May 2006 08:54:25 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FeX9z-0001d9-Tj
	for netconf-archive@lists.ietf.org; Fri, 12 May 2006 08:54:25 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FeX62-000OqG-LX
	for netconf-data@psg.com; Fri, 12 May 2006 12:50:18 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FeX61-000Opx-Rd
	for netconf@ops.ietf.org; Fri, 12 May 2006 12:50:18 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4CCoDk03771
	for <netconf@ops.ietf.org>; Fri, 12 May 2006 08:50:14 -0400 (EDT)
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: CallHome Notifications
Date: Fri, 12 May 2006 08:50:13 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4086CC04C@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: CallHome Notifications
Thread-Index: AcZ1wpxcur4anz7OSn2ozLB+yRpAqg==
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f

hi

This capability was added after there seemed to be working group
consensus that it was needed. The specification explicitly states that
it doesn't provide reliable delivery of notifications since I think it
makes sense to state up front what isn't supported in this alternative
method so that we don't have to spend a lot of cycles trying to get
parity with the main subscription method.

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 12 09:58:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FeY9f-0002LS-U6
	for netconf-archive@lists.ietf.org; Fri, 12 May 2006 09:58:07 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FeY9e-0006Co-HE
	for netconf-archive@lists.ietf.org; Fri, 12 May 2006 09:58:07 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FeY4Q-0002v9-7Y
	for netconf-data@psg.com; Fri, 12 May 2006 13:52:42 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FeY4P-0002ut-8l
	for netconf@ops.ietf.org; Fri, 12 May 2006 13:52:41 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4CDqck19042
	for <netconf@ops.ietf.org>; Fri, 12 May 2006 09:52:38 -0400 (EDT)
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: Some Proposed Edits from discussions (Notifications)
Date: Fri, 12 May 2006 09:52:36 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4086CC1C2@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Some Proposed Edits from discussions (Notifications)
Thread-Index: AcZ1y1N0UBW8J94ZRoqDixdrgEwYxQ==
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745

hi

From reading through different comments, these are some proposed edits
that seem straight forward. There were others proposed and then
discussed a bit more which I have not yet included in this list:

1. Section 1: Needs more discussion on motivation, requirements and
architecture.

2. Replace term 'Application Protocol' with 'Transport Protocol'

3. Consistency check
	- consistency within document, for example:
  - sect 5.1 page 25
          <event-class><configuration/><audit/></event-classes>
    is it event-class or event-classes?
    or is it eventClass as per the following on page 27:
          <eventClass><configuration/><audit/></eventClass>
  - sect 3.4.1 seems to contradict the description under "Named Profile"
    in sections 2.1.1 and 2.3.1
  - I see
      <capability>
        urn:ietf:params:xml:ns:netconf:notification:1.0
      </capability>
    and
        xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0
    and
       <rpc message-id=3D"101"
        xmlns=3D"urn:ietf:params:xml:ns:netconf:event:1.0">
    So there seems to be inconsistency here?

4. Create a Iana Considerations section with the following content

In order for new event classes to be allocated, the following
requirements must be met:
=20
  - WG consensus

  - detailed description of its purpose in the netconf protocol

  - detailed description of all manager and agent implementation
    requirements associated with the event class

  - It must be clear to developers how to determine that this
    is the appropriate event classification for a new notification type

5. Section 2.2.1)
Mention that there might be a big chunk of user defined data here.

6. Section 3.2)
- Change name from NetconfStateSchema to netconfNotificationSchema or
something=20
  similar

7. Section 7)
Better explain the dormant-active state of the call home subscription.
What is the=20
real difference between them ?

8. Section 7.1)
Add text to indicate that when an event occurs and if we run the
mixed-session mode the server should first check whether there is an
already open connection to the client.

9. Section 7.1.3.1.1)
Properly define element subscriber with Attributes like IpAddress,
PortNumber etc.=20

10. page 4, change NETCONF[NETCONF] --> NETCONF [NETCONF-PROTO]

11. In section 2, Add examples for each RPC operation.
There should be examples here instead of spread out
in the end of the document.

12 On page 6, In <create-subscription>, change "This command ..." to
"This operation ..."


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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 12 10:37:04 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FeYlM-0004cO-Cl
	for netconf-archive@lists.ietf.org; Fri, 12 May 2006 10:37:04 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FeYlM-0007f2-BN
	for netconf-archive@lists.ietf.org; Fri, 12 May 2006 10:37:04 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FeYeE-00077S-13
	for netconf-archive@lists.ietf.org; Fri, 12 May 2006 10:29:45 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FeYZl-0005CQ-1Y
	for netconf-data@psg.com; Fri, 12 May 2006 14:25:05 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FeYZk-0005Bj-0n
	for netconf@ops.ietf.org; Fri, 12 May 2006 14:25:04 +0000
Received: from mail.networksolutionsemail.com (ns-omr3.mgt.hosting.dc2.netsol.com [10.49.6.66])
	by ns-omrbm3.netsolmail.com (8.13.6/8.13.6) with SMTP id k4CEP3CU023745
	for <netconf@ops.ietf.org>; Fri, 12 May 2006 10:25:03 -0400
Received: (qmail 23068 invoked by uid 78); 12 May 2006 14:25:03 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.66 with SMTP; 12 May 2006 14:25:03 -0000
Message-ID: <44649A91.8090407@andybierman.com>
Date: Fri, 12 May 2006 07:24:17 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Verbiage
References: <713043CE8B8E1348AF3C546DBE02C1B4086CC012@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4086CC012@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
X-Spam-Score: -2.2 (--)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc

Sharon Chisholm wrote:
> hi
> 
> I've just read through the very interesting discussion on use of verbs.
> I would have joined in but I had this cold which brought me down a few
> million IQ points, so I figured it would be safer to wait.
> 

I think you missed a key point in this thread.
New RPCs are appropriate when they don't
replicate the existing RPCs.  Several WG members
are not convinced at all that subscription data
is anything other than config data.


Andy



> It seems there does seem to interest in having specialized verbs for
> subscriptions. I think talking about subscriptions as 'operational
> state' as appose to 'configuration data' was a great bit of
> clarification. I also thought the discussion about moving from low level
> programming languages (peek and pokes) to more procedural was also a
> good analogy.
> 
> I think we need to find a comfortable place between the two extremes of
> get/set and having a verb for every possible action on the box. Note
> that we already created 'specialized' verbs in the base protocol - we
> have get and get-config for example. We have been having to make these
> decisions within product and I don't think we have reached a really
> prescriptive criteria of when to create new verbs, I think the two big
> questions are
> 	- Is it possible to do it in the datamodel without exploiting
> side-effects?
> 	- Is the verb management related (reboot-box as appose to
> create-atm-interface, for example).
> 
> 
> As has been suggested, verbs, if there are not too many of them, make it
> much easer for operators and management applications to figure out what
> they need to do achieve their goal. It has been suggested that
> operations on the datamodel would be easer for the agent-side to
> develop. While I imagine that is true for the netconf stack, I think
> that is ignoring the rest of the network element. Once the command has
> been received by the agent, it them gets passed onto routines that do
> the real work. In my experience, these real routines are not doing
> peek/poke operations either. The network element must re-assemble the
> command from the collection of things that have been provided in the
> data model and realize that the user is trying to create a subscription.
> 
> Pushing things to the datamodel starts to look like
> 
> 
> I'd like to subscribe ->  <edit-config> <data/> </edit-config> ->   
> 
> 					|
> 					V
> 
> -> </edit-config> <data/> </edit-config> -> is this valid edit-config ->
> Oh, they would like to subscribe -> is it a valid subscription -> ok,
> I'll subscribe them then
> 
> And in this case, is it possible for the edit-config to be valid, but
> have errors that prevent the subscription from being created?
> 
> 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: <http://ops.ietf.org/lists/netconf/>
> 
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 12 14:42:26 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fecao-0005d4-9o
	for netconf-archive@lists.ietf.org; Fri, 12 May 2006 14:42:26 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fecal-0003FH-RI
	for netconf-archive@lists.ietf.org; Fri, 12 May 2006 14:42:26 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FecUw-000LmG-Sf
	for netconf-data@psg.com; Fri, 12 May 2006 18:36:22 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FecUw-000Lm4-3n
	for netconf@ops.ietf.org; Fri, 12 May 2006 18:36:22 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4CIaJk03045
	for <netconf@ops.ietf.org>; Fri, 12 May 2006 14:36:19 -0400 (EDT)
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: Verbiage
Date: Fri, 12 May 2006 14:36:17 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4086CC89F@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Verbiage
Thread-Index: AcZ1z98ow1/7LuRBTM6Go2bHJmovUgAIgeaA
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

hi

<Andy>

I think you missed a key point in this thread.
New RPCs are appropriate when they don't
replicate the existing RPCs.  Several WG members
are not convinced at all that subscription data
is anything other than config data.

</Andy>

No, I don't think I did.  I thought people raised some very good points
to consider when deciding whether or not to add new verbs. Just whether
existing verbs and a chunk of data model *could* be used obviously isn't
the only criteria or we wouldn't have a made some of the decisions we
made in the base protocol.=20

Usability by the client and ease of integration into the network itself
need to also be considered.

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 15 20:26:34 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FfnOU-0002VX-Qs
	for netconf-archive@lists.ietf.org; Mon, 15 May 2006 20:26:34 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FfnOQ-0004sJ-F4
	for netconf-archive@lists.ietf.org; Mon, 15 May 2006 20:26:34 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FfnGC-000AA4-Hz
	for netconf-data@psg.com; Tue, 16 May 2006 00:18:00 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.51] (helo=ns-omrbm1.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FfnGB-000A9q-Ah
	for netconf@ops.ietf.org; Tue, 16 May 2006 00:17:59 +0000
Received: from mail.networksolutionsemail.com (ns-omr1.mgt.hosting.dc2.netsol.com [10.49.6.64])
	by ns-omrbm1.netsolmail.com (8.13.6/8.13.6) with SMTP id k4G0Hwuc029863
	for <netconf@ops.ietf.org>; Mon, 15 May 2006 20:17:58 -0400
Received: (qmail 12277 invoked by uid 78); 16 May 2006 00:17:58 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.64 with SMTP; 16 May 2006 00:17:58 -0000
Message-ID: <44691A34.8030608@andybierman.com>
Date: Mon, 15 May 2006 17:17:56 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: nested operation attribute interoperability
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135

Hi,

I am trying to create an matrix to help me optimize code
related to the processing of the nested operation attribute.
It would be nice if vendors handled this in an interoperable manner.

I try to follow the Postel Principle and not generate any
errors unless it is mandatory.  I use containers to make
it easy to apply a 'delete' operation to an entire table,
as well as easier access control configuration.

At any given point in a <config> subtree, there is a 'parent'
edit operation and a potentially different 'child' edit op.
Obviously the parent edit-op has precedence.  The start state
is allowed to be 'none', but once the operation is set, it can
never go back to 'none'.

This table shows each parent --> child edit-op transition,
and whether it is valid or an error.  My question to the WG
is whether this table is correct or not:

child ->  create   merge   replace   delete
parent
    |
 
   none      V        V        V         V
 
  create     x        V-1      V-1       E-1

  merge      V-3      x        V         V-3    

  replace    V-3      V        x         V-3

  delete     E-1      V-2      V-2       x


Notes:

V:    valid, no errors or warnings

V-1:  valid, but create has precedence.
      Only merge-with-nothing or replace-nothing scenarios are valid.

V-2:  valid, but has no effect because delete has precedence

V-3:  valid, but create or delete rules now in affect for next child

E-1:  'bad-attribute' or 'operation-failed' error (not sure which)
      Requirements for create and delete cannot both be met
      in the same subtree, regardless of the data model

  x:  no edit-op change



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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 16 02:25:58 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fft0I-0003Gp-Gq
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 02:25:58 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fft0I-0001uU-E0
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 02:25:58 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1Fft0G-0001Gn-8Y
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 02:25:58 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Ffstr-0002bn-99
	for netconf-data@psg.com; Tue, 16 May 2006 06:19:19 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1Ffstq-0002bb-38
	for netconf@ops.ietf.org; Tue, 16 May 2006 06:19:18 +0000
Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id 6999540;
	Tue, 16 May 2006 08:19:16 +0200 (CEST)
Date: Tue, 16 May 2006 08:19:06 +0200 (CEST)
Message-Id: <20060516.081906.64513942.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: netconf@ops.ietf.org
Subject: Re: nested operation attribute interoperability
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <44691A34.8030608@andybierman.com>
References: <44691A34.8030608@andybierman.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a

Andy Bierman <ietf@andybierman.com> wrote:
> Hi,
> 
> I am trying to create an matrix to help me optimize code
> related to the processing of the nested operation attribute.
> It would be nice if vendors handled this in an interoperable manner.

Absolutely.

> I try to follow the Postel Principle and not generate any
> errors unless it is mandatory.  I use containers to make
> it easy to apply a 'delete' operation to an entire table,
> as well as easier access control configuration.
> 
> At any given point in a <config> subtree, there is a 'parent'
> edit operation and a potentially different 'child' edit op.
> Obviously the parent edit-op has precedence.  The start state
> is allowed to be 'none', but once the operation is set, it can
> never go back to 'none'.
> 
> This table shows each parent --> child edit-op transition,
> and whether it is valid or an error.  My question to the WG
> is whether this table is correct or not:
> 
> child ->  create   merge   replace   delete
> parent
>     |
>  
>    none      V        V        V         V
>  
>   create     x        V-1      V-1       E-1
> 
>   merge      V-3      x        V         V-3    
> 
>   replace    V-3      V        x         V-3
> 
>   delete     E-1      V-2      V-2       x

Our table is a bit different, and I think the reason is b/c you have a
different meaning of the operation 'replace' than us (and others such
as juniper).  This has been discussed before (see the thread "Second
Example in section 7.2 of netconf-proto").  Your 'replace' is more of
a 'merge'.  Personally I think it is even more important to have an
interopable interpretation of the meaning of these operations.

Anyway, this would be our table, differencies to yours are marked with
(*):

child ->  create   merge   replace   delete
parent
    |
 
   none      V        V        V         V
 
  create     x        V-1      E-1(*)    E-1

  merge      V-3      x        V-4(*)    V-3    

  replace    E-1(*)   V        x         E-1(*)

  delete     E-1      V-2      E-1(*)    x


> Notes:
> 
> V:    valid, no errors or warnings
> 
> V-1:  valid, but create has precedence.
>       Only merge-with-nothing or replace-nothing scenarios are valid.
> 
> V-2:  valid, but has no effect because delete has precedence
> 
> V-3:  valid, but create or delete rules now in affect for next child
> 
> E-1:  'bad-attribute' or 'operation-failed' error (not sure which)
>       Requirements for create and delete cannot both be met
>       in the same subtree, regardless of the data model
> 
>   x:  no edit-op change

V-4:   valid, but replace rule now in affect for next child

For errors (E-1), we use 'bad-attribute'.  (currently with error-type
'application', which I think might be wrong, it should probably be
'protocol'.  Deciding correct error-type is sometimes tricky...)


/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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 16 05:52:50 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FfwEU-0008GF-0l
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 05:52:50 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FfwET-0003wq-Kc
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 05:52:50 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Ffw8M-000ER1-Vv
	for netconf-data@psg.com; Tue, 16 May 2006 09:46:30 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Ffw8L-000EQn-MI
	for netconf@ops.ietf.org; Tue, 16 May 2006 09:46:30 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.hosting.dc2.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k4G9kSi5003832
	for <netconf@ops.ietf.org>; Tue, 16 May 2006 05:46:29 -0400
Received: (qmail 12901 invoked by uid 78); 16 May 2006 09:46:28 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 16 May 2006 09:46:28 -0000
Message-ID: <44699F75.7060800@andybierman.com>
Date: Tue, 16 May 2006 02:46:29 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC: netconf@ops.ietf.org
Subject: Re: nested operation attribute interoperability
References: <44691A34.8030608@andybierman.com> <20060516.081906.64513942.mbj@tail-f.com>
In-Reply-To: <20060516.081906.64513942.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>> Hi,
>>
>> I am trying to create an matrix to help me optimize code
>> related to the processing of the nested operation attribute.
>> It would be nice if vendors handled this in an interoperable manner.
> 
> Absolutely.
> 
>> I try to follow the Postel Principle and not generate any
>> errors unless it is mandatory.  I use containers to make
>> it easy to apply a 'delete' operation to an entire table,
>> as well as easier access control configuration.
>>
>> At any given point in a <config> subtree, there is a 'parent'
>> edit operation and a potentially different 'child' edit op.
>> Obviously the parent edit-op has precedence.  The start state
>> is allowed to be 'none', but once the operation is set, it can
>> never go back to 'none'.
>>
>> This table shows each parent --> child edit-op transition,
>> and whether it is valid or an error.  My question to the WG
>> is whether this table is correct or not:
>>
>> child ->  create   merge   replace   delete
>> parent
>>     |
>>  
>>    none      V        V        V         V
>>  
>>   create     x        V-1      V-1       E-1
>>
>>   merge      V-3      x        V         V-3    
>>
>>   replace    V-3      V        x         V-3
>>
>>   delete     E-1      V-2      V-2       x
> 
> Our table is a bit different, and I think the reason is b/c you have a
> different meaning of the operation 'replace' than us (and others such
> as juniper).  This has been discussed before (see the thread "Second
> Example in section 7.2 of netconf-proto").  Your 'replace' is more of
> a 'merge'.  Personally I think it is even more important to have an
> interopable interpretation of the meaning of these operations.


No -- we decided your interpretation of replace is correct.
I am changing my code for replace to match it.


> 
> Anyway, this would be our table, differencies to yours are marked with
> (*):
> 
> child ->  create   merge   replace   delete
> parent
>     |
>  
>    none      V        V        V         V
>  
>   create     x        V-1      E-1(*)    E-1
> 
>   merge      V-3      x        V-4(*)    V-3    
> 
>   replace    E-1(*)   V        x         E-1(*)
> 
>   delete     E-1      V-2      E-1(*)    x
> 
> 
>> Notes:
>>
>> V:    valid, no errors or warnings
>>
>> V-1:  valid, but create has precedence.
>>       Only merge-with-nothing or replace-nothing scenarios are valid.
>>
>> V-2:  valid, but has no effect because delete has precedence
>>
>> V-3:  valid, but create or delete rules now in affect for next child
>>
>> E-1:  'bad-attribute' or 'operation-failed' error (not sure which)
>>       Requirements for create and delete cannot both be met
>>       in the same subtree, regardless of the data model
>>



I think your E-1 is wrong.
If the current subtree is empty, then replace is the
same as create.  My E-1 is only valid for merge or
replace if it is also valid for create.

Replace does not fail if there is nothing to replace.
Only delete fails if there is nothing to delete,
or create fails if the data is already there.


>>   x:  no edit-op change
> 
> V-4:   valid, but replace rule now in affect for next child
> 
> For errors (E-1), we use 'bad-attribute'.  (currently with error-type
> 'application', which I think might be wrong, it should probably be
> 'protocol'.  Deciding correct error-type is sometimes tricky...)
> 
> 
> /martin
> 

Andy


> 
> 
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 16 07:48:58 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ffy2s-0003Q5-B8
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 07:48:58 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ffx16-0006PN-LT
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 06:43:04 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FfwnR-0003k9-RO
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 06:28:59 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Ffwic-000GLT-Rg
	for netconf-data@psg.com; Tue, 16 May 2006 10:23:58 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1Ffwib-000GLH-Kq
	for netconf@ops.ietf.org; Tue, 16 May 2006 10:23:57 +0000
Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id 7F11240;
	Tue, 16 May 2006 12:23:56 +0200 (CEST)
Date: Tue, 16 May 2006 12:23:45 +0200 (CEST)
Message-Id: <20060516.122345.32981761.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: netconf@ops.ietf.org
Subject: Re: nested operation attribute interoperability
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <44699F75.7060800@andybierman.com>
References: <44691A34.8030608@andybierman.com>
	<20060516.081906.64513942.mbj@tail-f.com>
	<44699F75.7060800@andybierman.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793

Andy Bierman <ietf@andybierman.com> wrote:
> > child ->  create   merge   replace   delete
> > parent
> >     |
> >  
> >    none      V        V        V         V
> >  
> >   create     x        V-1      E-1(*)    E-1
> > 
> >   merge      V-3      x        V-4(*)    V-3    
> > 
> >   replace    E-1(*)   V        x         E-1(*)
> > 
> >   delete     E-1      V-2      E-1(*)    x
> > 
> > 
> >> Notes:
> >>
> >> V:    valid, no errors or warnings
> >>
> >> V-1:  valid, but create has precedence.
> >>       Only merge-with-nothing or replace-nothing scenarios are valid.
> >>
> >> V-2:  valid, but has no effect because delete has precedence
> >>
> >> V-3:  valid, but create or delete rules now in affect for next child
> >>
> >> E-1:  'bad-attribute' or 'operation-failed' error (not sure which)
> >>       Requirements for create and delete cannot both be met
> >>       in the same subtree, regardless of the data model
> >>
> 
> 
> 
> I think your E-1 is wrong.

Do you mean the first one (replace when parent is create)?   The only
reason for allowing this is due to "be liberal in what you accept",
right?  I guess we could also allow delete when parent is create by
the same reasoning.

Allowing create under a replace might make sense though, if we want to
be liberal.

I'm happy to change this code to make it interopable.


/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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 16 08:42:15 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FfysR-0001IA-DM
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 08:42:15 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FfysQ-0004TV-OT
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 08:42:15 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Ffygk-000Mqj-Gr
	for netconf-data@psg.com; Tue, 16 May 2006 12:30:10 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FfygY-000MoS-I2
	for netconf@ops.ietf.org; Tue, 16 May 2006 12:29:58 +0000
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 66C234F037D
	for <netconf@ops.ietf.org>; Tue, 16 May 2006 14:29:57 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 16 May 2006 14:29:57 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 16 May 2006 14:29:56 +0200
Message-ID: <4469C5C4.2030606@ericsson.com>
Date: Tue, 16 May 2006 14:29:56 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Verbiage
References: <713043CE8B8E1348AF3C546DBE02C1B4086CC89F@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4086CC89F@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 May 2006 12:29:57.0033 (UTC) FILETIME=[70FFD990:01C678E4]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64

Hello,
I am more disturbed by the fact that we have two filter mechanism - named profile and 
filter in the draft. These seem really to do the same thing one using a data model while 
the other trying to conform to a verb type solution.

Please merge the two! You could kill the filter or say that it updates the stored 
filter/named profile.


Myself I am more on the data model side but can we settle for Andy's compromise:
Set up what to do using a data model then start/stop subscription using a very simple 
verb/operation?

regards Balazs

Sharon Chisholm wrote:
> hi
> 
> <Andy>
> 
> I think you missed a key point in this thread.
> New RPCs are appropriate when they don't
> replicate the existing RPCs.  Several WG members
> are not convinced at all that subscription data
> is anything other than config data.
> 
> </Andy>
> 
> No, I don't think I did.  I thought people raised some very good points
> to consider when deciding whether or not to add new verbs. Just whether
> existing verbs and a chunk of data model *could* be used obviously isn't
> the only criteria or we wouldn't have a made some of the decisions we
> made in the base protocol. 
> 
> Usability by the client and ease of integration into the network itself
> need to also be considered.
> 
> 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: <http://ops.ietf.org/lists/netconf/>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 16 10:29:28 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fg0YC-0005XO-Gs
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 10:29:28 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fg0YB-0000cO-S6
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 10:29:28 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fg0RK-0004Aj-Jd
	for netconf-data@psg.com; Tue, 16 May 2006 14:22:22 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1Fg0RJ-0004AW-6z
	for netconf@ops.ietf.org; Tue, 16 May 2006 14:22:21 +0000
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 533EC4F03D4
	for <netconf@ops.ietf.org>; Tue, 16 May 2006 16:22:20 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 16 May 2006 16:22:20 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 16 May 2006 16:22:19 +0200
Message-ID: <4469E01A.9040604@ericsson.com>
Date: Tue, 16 May 2006 16:22:18 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: event classes (sec. 3.5)
References: <445B7A1C.9090803@andybierman.com>
In-Reply-To: <445B7A1C.9090803@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 May 2006 14:22:19.0842 (UTC) FILETIME=[2406DA20:01C678F4]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4

Hello
- FAULT event - OK, but could specify the details somewhat even if they are optional e.g. 
eventsource, probable cause,  severity, specific problem
- CONFIGURATION - OK
- STATE - OK
- AUDIT event seems a bit overkill. I think event classes should mainly speak about
	why/on what occasion do  we send that specific event class
	what information does an event class carry
	what handling is expected of the specific event class
Here we only have part of the third point. You could have an audit trail of state changes 
or a trail of configuration changes etc. I don't see this as a separate event class. It 
should be merged with something or removed.
- DATA DUMP event should me merged with configuration event. The main difference is that 
it can also carry state information. But thats already included in State event, so kill 
data dump.
- Ericsson needs MAINTENANCE events. See Jurgens requirement page: "notify about delayed 
results of long running RPCs [BL]". I am not totally happy with the name of the event 
class, but I like the idea behind it. If the draft misses this Ericsson will have to do 
some dirty workaround.
- METRICS is certainly out of scope although I don't see any real problem with it. We must 
note however that Netconf events are probably unsuitable for HIGH volume performance data 
transfer.
- HEART BEAT - OK
- INFORMATION event is really an extension mechanism. OK.
- SYSLOG: We spoke a lot about transferring syslog via events, but please could someone 
say who really has a requirement to do this! If we really have the requirement Jurgen 
please add it to your page!
- SECURITY - mentioned in the initial list, but not described later. As I see it security 
related notifications can be carried as fault or state events, so I don't see a need for 
this event class.

Balazs

Andy Bierman wrote:
> Hi,
> 
> This section is very under-specified.
> 
> IMO, it is impossible for independent developers
> to select classifications in an interoperable manner.
> 
> It is really not at all clear why we need audit, data,
> maintenance, metrics, information, and syslog classes at all.
> 
> Most of these are totally redundant.
> 
> Metrics is out of scope.
> 
> Syslog is not a proper member of this classification set.
> In XML, we use namespaces to identify content format,
> such as syslog/RAW, syslog/COOKED, acme/TOASTED, etc.
> The notification <data> section will be just like
> the <config> or <data> elements already defined in
> the protocol.
> 
> 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: <http://ops.ietf.org/lists/netconf/>


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 16 11:13:30 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fg1Eo-0001IZ-8i
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 11:13:30 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fg1Em-0003Nl-Rb
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 11:13:30 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fg19P-0006xT-HJ
	for netconf-data@psg.com; Tue, 16 May 2006 15:07:55 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fg19O-0006xE-BS
	for netconf@ops.ietf.org; Tue, 16 May 2006 15:07:54 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.hosting.dc2.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k4GF7naV009682
	for <netconf@ops.ietf.org>; Tue, 16 May 2006 11:07:51 -0400
Received: (qmail 8514 invoked by uid 78); 16 May 2006 15:07:49 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 16 May 2006 15:07:49 -0000
Message-ID: <4469EABF.9020301@andybierman.com>
Date: Tue, 16 May 2006 08:07:43 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: event classes (sec. 3.5)
References: <445B7A1C.9090803@andybierman.com> <4469E01A.9040604@ericsson.com>
In-Reply-To: <4469E01A.9040604@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86

Balazs Lengyel wrote:

IMO, the only thing that matters here is that the
classifications are clearly defined so that any
2 independent implementors will pick the same
classification for the same new notification message.

There is no way that can happen given the current text.
The descriptions of some of them are too vague, and there
is too much overlap.

Andy


> Hello
> - FAULT event - OK, but could specify the details somewhat even if they 
> are optional e.g. eventsource, probable cause,  severity, specific problem
> - CONFIGURATION - OK
> - STATE - OK
> - AUDIT event seems a bit overkill. I think event classes should mainly 
> speak about
>     why/on what occasion do  we send that specific event class
>     what information does an event class carry
>     what handling is expected of the specific event class
> Here we only have part of the third point. You could have an audit trail 
> of state changes or a trail of configuration changes etc. I don't see 
> this as a separate event class. It should be merged with something or 
> removed.
> - DATA DUMP event should me merged with configuration event. The main 
> difference is that it can also carry state information. But thats 
> already included in State event, so kill data dump.
> - Ericsson needs MAINTENANCE events. See Jurgens requirement page: 
> "notify about delayed results of long running RPCs [BL]". I am not 
> totally happy with the name of the event class, but I like the idea 
> behind it. If the draft misses this Ericsson will have to do some dirty 
> workaround.
> - METRICS is certainly out of scope although I don't see any real 
> problem with it. We must note however that Netconf events are probably 
> unsuitable for HIGH volume performance data transfer.
> - HEART BEAT - OK
> - INFORMATION event is really an extension mechanism. OK.
> - SYSLOG: We spoke a lot about transferring syslog via events, but 
> please could someone say who really has a requirement to do this! If we 
> really have the requirement Jurgen please add it to your page!
> - SECURITY - mentioned in the initial list, but not described later. As 
> I see it security related notifications can be carried as fault or state 
> events, so I don't see a need for this event class.
> 
> Balazs
> 
> Andy Bierman wrote:
>> Hi,
>>
>> This section is very under-specified.
>>
>> IMO, it is impossible for independent developers
>> to select classifications in an interoperable manner.
>>
>> It is really not at all clear why we need audit, data,
>> maintenance, metrics, information, and syslog classes at all.
>>
>> Most of these are totally redundant.
>>
>> Metrics is out of scope.
>>
>> Syslog is not a proper member of this classification set.
>> In XML, we use namespaces to identify content format,
>> such as syslog/RAW, syslog/COOKED, acme/TOASTED, etc.
>> The notification <data> section will be just like
>> the <config> or <data> elements already defined in
>> the protocol.
>>
>> 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: <http://ops.ietf.org/lists/netconf/>
> 
> 
> -- 
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 16 11:17:29 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fg1If-0001jD-It
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 11:17:29 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fg1Id-0003U6-1C
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 11:17:29 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fg1EE-0007Fb-9u
	for netconf-data@psg.com; Tue, 16 May 2006 15:12:54 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1Fg1ED-0007FO-8w
	for netconf@ops.ietf.org; Tue, 16 May 2006 15:12:53 +0000
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 405444F0001
	for <netconf@ops.ietf.org>; Tue, 16 May 2006 17:12:52 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 16 May 2006 17:12:51 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 16 May 2006 17:12:51 +0200
Message-ID: <4469EBF2.2080200@ericsson.com>
Date: Tue, 16 May 2006 17:12:50 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To:  netconf@ops.ietf.org
Subject: Notification Filtering
References: <20060507.000937.69981240.mbj@tail-f.com>	<20060511.221844.109344212.mbj@tail-f.com>	<4463A7EB.9010307@andybierman.com> <20060511.231927.126912941.mbj@tail-f.com>
In-Reply-To: <20060511.231927.126912941.mbj@tail-f.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 May 2006 15:12:51.0231 (UTC) FILETIME=[32E01AF0:01C678FB]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007

Hello,
To me it seems that an important sentence is missing from the notifications draft about 
filters. The draft says:
"The format of this parameter is the same as that of the filter parameter in the NETCONF 
protocol operations."

But it does not say that filters will be applied against the data content of the 
notification or maybe just part of the notification.

One could just as well imagine filtering against the source of the notifications e.g. I am 
interested only in fault-notifications coming from one of the ethernet interface cards so 
I apply a filter against the running datastore's data
XPATH: /top/interfaces/ethernet-interfaces

Please clarify! Also we need some kind of statement exactly which part of the notification 
wil be checked.


regards 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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 16 11:28:28 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fg1TG-0004Gh-Bx
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 11:28:28 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fg1TF-0004TA-Tb
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 11:28:26 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fg1Li-0007oH-Ux
	for netconf-data@psg.com; Tue, 16 May 2006 15:20:38 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1Fg1Lh-0007nZ-IV
	for netconf@ops.ietf.org; Tue, 16 May 2006 15:20:37 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DD5D34F0002;
	Tue, 16 May 2006 17:18:30 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 16 May 2006 17:18:30 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 16 May 2006 17:18:30 +0200
Message-ID: <4469ED45.6020103@ericsson.com>
Date: Tue, 16 May 2006 17:18:29 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: event classes (sec. 3.5)
References: <445B7A1C.9090803@andybierman.com> <4469E01A.9040604@ericsson.com> <4469EABF.9020301@andybierman.com>
In-Reply-To: <4469EABF.9020301@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 May 2006 15:18:30.0526 (UTC) FILETIME=[FD1C69E0:01C678FB]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8

Hello,
If we provided the following set of data for each notification(why event?) class would 
that be enough ?
- Definition
- Events that trigger the notification
- Expected data, might contain optional parts
- expected handling/usage

Or do we need more ? What ?

Balazs

Andy Bierman wrote:
> Balazs Lengyel wrote:
> 
> IMO, the only thing that matters here is that the
> classifications are clearly defined so that any
> 2 independent implementors will pick the same
> classification for the same new notification message.
> 
> There is no way that can happen given the current text.
> The descriptions of some of them are too vague, and there
> is too much overlap.
> 
> Andy
> 
> 
>> Hello
>> - FAULT event - OK, but could specify the details somewhat even if 
>> they are optional e.g. eventsource, probable cause,  severity, 
>> specific problem
>> - CONFIGURATION - OK
>> - STATE - OK
>> - AUDIT event seems a bit overkill. I think event classes should 
>> mainly speak about
>>     why/on what occasion do  we send that specific event class
>>     what information does an event class carry
>>     what handling is expected of the specific event class
>> Here we only have part of the third point. You could have an audit 
>> trail of state changes or a trail of configuration changes etc. I 
>> don't see this as a separate event class. It should be merged with 
>> something or removed.
>> - DATA DUMP event should me merged with configuration event. The main 
>> difference is that it can also carry state information. But thats 
>> already included in State event, so kill data dump.
>> - Ericsson needs MAINTENANCE events. See Jurgens requirement page: 
>> "notify about delayed results of long running RPCs [BL]". I am not 
>> totally happy with the name of the event class, but I like the idea 
>> behind it. If the draft misses this Ericsson will have to do some 
>> dirty workaround.
>> - METRICS is certainly out of scope although I don't see any real 
>> problem with it. We must note however that Netconf events are probably 
>> unsuitable for HIGH volume performance data transfer.
>> - HEART BEAT - OK
>> - INFORMATION event is really an extension mechanism. OK.
>> - SYSLOG: We spoke a lot about transferring syslog via events, but 
>> please could someone say who really has a requirement to do this! If 
>> we really have the requirement Jurgen please add it to your page!
>> - SECURITY - mentioned in the initial list, but not described later. 
>> As I see it security related notifications can be carried as fault or 
>> state events, so I don't see a need for this event class.
>>
>> Balazs
>>
>> Andy Bierman wrote:
>>> Hi,
>>>
>>> This section is very under-specified.
>>>
>>> IMO, it is impossible for independent developers
>>> to select classifications in an interoperable manner.
>>>
>>> It is really not at all clear why we need audit, data,
>>> maintenance, metrics, information, and syslog classes at all.
>>>
>>> Most of these are totally redundant.
>>>
>>> Metrics is out of scope.
>>>
>>> Syslog is not a proper member of this classification set.
>>> In XML, we use namespaces to identify content format,
>>> such as syslog/RAW, syslog/COOKED, acme/TOASTED, etc.
>>> The notification <data> section will be just like
>>> the <config> or <data> elements already defined in
>>> the protocol.
>>>
>>> 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: <http://ops.ietf.org/lists/netconf/>
>>
>>
>> -- 
>> to unsubscribe send a message to netconf-request@ops.ietf.org with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
>>
>>
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 16 11:34:15 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fg1Yt-0006YE-S6
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 11:34:15 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fg1Yt-0005HW-H7
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 11:34:15 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fg1L3-0007jT-C0
	for netconf-data@psg.com; Tue, 16 May 2006 15:19:57 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fg1L2-0007jI-GZ
	for netconf@ops.ietf.org; Tue, 16 May 2006 15:19:56 +0000
Received: from mail.networksolutionsemail.com (ns-omr2.mgt.hosting.dc2.netsol.com [10.49.6.65])
	by ns-omrbm2.netsolmail.com (8.13.6/8.13.6) with SMTP id k4GFJs2r027832
	for <netconf@ops.ietf.org>; Tue, 16 May 2006 11:19:55 -0400
Received: (qmail 13134 invoked by uid 78); 16 May 2006 15:19:52 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 16 May 2006 15:19:52 -0000
Message-ID: <4469ED91.9040204@andybierman.com>
Date: Tue, 16 May 2006 08:19:45 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC: netconf@ops.ietf.org
Subject: Re: nested operation attribute interoperability
References: <44691A34.8030608@andybierman.com>	<20060516.081906.64513942.mbj@tail-f.com>	<44699F75.7060800@andybierman.com> <20060516.122345.32981761.mbj@tail-f.com>
In-Reply-To: <20060516.122345.32981761.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>>> child ->  create   merge   replace   delete
>>> parent
>>>     |
>>>  
>>>    none      V        V        V         V
>>>  
>>>   create     x        V-1      E-1(*)    E-1
>>>
>>>   merge      V-3      x        V-4(*)    V-3    
>>>
>>>   replace    E-1(*)   V        x         E-1(*)
>>>
>>>   delete     E-1      V-2      E-1(*)    x
>>>
>>>
>>>> Notes:
>>>>
>>>> V:    valid, no errors or warnings
>>>>
>>>> V-1:  valid, but create has precedence.
>>>>       Only merge-with-nothing or replace-nothing scenarios are valid.
>>>>
>>>> V-2:  valid, but has no effect because delete has precedence
>>>>
>>>> V-3:  valid, but create or delete rules now in affect for next child
>>>>
>>>> E-1:  'bad-attribute' or 'operation-failed' error (not sure which)
>>>>       Requirements for create and delete cannot both be met
>>>>       in the same subtree, regardless of the data model


Both these error codes are wrong for my E-1.
This is clearly a 'data-exists' error.
There is no way you could get to <b> in the example
below unless <a> existed, which violates the 'create' rules.

edit-config <config> contents
------------------------------

<a operation="create">
   <b operation="replace"/>
</a>


Current Config          Result
------------------------------
empty                   ok
<a/>                    data-exists error
<a><b/></a>             data-exists error



>>>>
>>
>>
>> I think your E-1 is wrong.
> 
> Do you mean the first one (replace when parent is create)?   The only
> reason for allowing this is due to "be liberal in what you accept",
> right?  I guess we could also allow delete when parent is create by
> the same reasoning.


Also because there is no text whatsoever in the document
that declares an error condition if 'replace' is invoked
against an empty portion of the target config.


> 
> Allowing create under a replace might make sense though, if we want to
> be liberal.
> 
> I'm happy to change this code to make it interopable.
> 
> 
> /martin


Andy


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 16 11:50:53 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fg1oy-0003Hp-WF
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 11:50:53 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fg1oy-00071l-Hn
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 11:50:52 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fg1hH-0009L4-EI
	for netconf-data@psg.com; Tue, 16 May 2006 15:42:55 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fg1hG-0009Kr-ES
	for netconf@ops.ietf.org; Tue, 16 May 2006 15:42:54 +0000
Received: from mail.networksolutionsemail.com (ns-omr2.mgt.hosting.dc2.netsol.com [10.49.6.65])
	by ns-omrbm2.netsolmail.com (8.13.6/8.13.6) with SMTP id k4GFgnnD029214
	for <netconf@ops.ietf.org>; Tue, 16 May 2006 11:42:53 -0400
Received: (qmail 10008 invoked by uid 78); 16 May 2006 15:42:43 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 16 May 2006 15:42:43 -0000
Message-ID: <4469F2EC.7040508@andybierman.com>
Date: Tue, 16 May 2006 08:42:36 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: event classes (sec. 3.5)
References: <445B7A1C.9090803@andybierman.com> <4469E01A.9040604@ericsson.com> <4469EABF.9020301@andybierman.com> <4469ED45.6020103@ericsson.com>
In-Reply-To: <4469ED45.6020103@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab

Balazs Lengyel wrote:
> Hello,
> If we provided the following set of data for each notification(why 
> event?) class would that be enough ?

I like the term notification classification better.


> - Definition
> - Events that trigger the notification
> - Expected data, might contain optional parts
> - expected handling/usage
> 
> Or do we need more ? What ?


We don't have any notification definition template for
XSD, RelaxNG or whatever.  If one were to define such
a template, there would be a field for the event-class.

We need a classification set that is complete and
also easy to decide which classification to choose.
Otherwise, standard filters based on event-type will be mostly worthless
because no 2 agents classify notifications the same way.

Since this entire solution scales so poorly, without useful
filtering for session-based manager ease-of-use, it is
totally pointless.

> 
> Balazs


Andy


> 
> Andy Bierman wrote:
>> Balazs Lengyel wrote:
>>
>> IMO, the only thing that matters here is that the
>> classifications are clearly defined so that any
>> 2 independent implementors will pick the same
>> classification for the same new notification message.
>>
>> There is no way that can happen given the current text.
>> The descriptions of some of them are too vague, and there
>> is too much overlap.
>>
>> Andy
>>
>>
>>> Hello
>>> - FAULT event - OK, but could specify the details somewhat even if 
>>> they are optional e.g. eventsource, probable cause,  severity, 
>>> specific problem
>>> - CONFIGURATION - OK
>>> - STATE - OK
>>> - AUDIT event seems a bit overkill. I think event classes should 
>>> mainly speak about
>>>     why/on what occasion do  we send that specific event class
>>>     what information does an event class carry
>>>     what handling is expected of the specific event class
>>> Here we only have part of the third point. You could have an audit 
>>> trail of state changes or a trail of configuration changes etc. I 
>>> don't see this as a separate event class. It should be merged with 
>>> something or removed.
>>> - DATA DUMP event should me merged with configuration event. The main 
>>> difference is that it can also carry state information. But thats 
>>> already included in State event, so kill data dump.
>>> - Ericsson needs MAINTENANCE events. See Jurgens requirement page: 
>>> "notify about delayed results of long running RPCs [BL]". I am not 
>>> totally happy with the name of the event class, but I like the idea 
>>> behind it. If the draft misses this Ericsson will have to do some 
>>> dirty workaround.
>>> - METRICS is certainly out of scope although I don't see any real 
>>> problem with it. We must note however that Netconf events are 
>>> probably unsuitable for HIGH volume performance data transfer.
>>> - HEART BEAT - OK
>>> - INFORMATION event is really an extension mechanism. OK.
>>> - SYSLOG: We spoke a lot about transferring syslog via events, but 
>>> please could someone say who really has a requirement to do this! If 
>>> we really have the requirement Jurgen please add it to your page!
>>> - SECURITY - mentioned in the initial list, but not described later. 
>>> As I see it security related notifications can be carried as fault or 
>>> state events, so I don't see a need for this event class.
>>>
>>> Balazs
>>>
>>> Andy Bierman wrote:
>>>> Hi,
>>>>
>>>> This section is very under-specified.
>>>>
>>>> IMO, it is impossible for independent developers
>>>> to select classifications in an interoperable manner.
>>>>
>>>> It is really not at all clear why we need audit, data,
>>>> maintenance, metrics, information, and syslog classes at all.
>>>>
>>>> Most of these are totally redundant.
>>>>
>>>> Metrics is out of scope.
>>>>
>>>> Syslog is not a proper member of this classification set.
>>>> In XML, we use namespaces to identify content format,
>>>> such as syslog/RAW, syslog/COOKED, acme/TOASTED, etc.
>>>> The notification <data> section will be just like
>>>> the <config> or <data> elements already defined in
>>>> the protocol.
>>>>
>>>> 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: <http://ops.ietf.org/lists/netconf/>
>>>
>>>
>>> -- 
>>> to unsubscribe send a message to netconf-request@ops.ietf.org with
>>> the word 'unsubscribe' in a single line as the message text body.
>>> archive: <http://ops.ietf.org/lists/netconf/>
>>>
>>>
>>
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 16 12:07:14 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fg24o-00006P-Ix
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 12:07:14 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fg24n-0007uE-OL
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 12:07:14 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fg1xe-000AbD-Pb
	for netconf-data@psg.com; Tue, 16 May 2006 15:59:50 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1Fg1xc-000Aay-Rt
	for netconf@ops.ietf.org; Tue, 16 May 2006 15:59:49 +0000
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E2735CBC;
	Tue, 16 May 2006 17:59:47 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 16 May 2006 17:59:47 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 16 May 2006 17:59:46 +0200
Message-ID: <4469F6F1.8000008@ericsson.com>
Date: Tue, 16 May 2006 17:59:45 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: event classes (sec. 3.5)
References: <445B7A1C.9090803@andybierman.com> <4469E01A.9040604@ericsson.com> <4469EABF.9020301@andybierman.com> <4469ED45.6020103@ericsson.com> <4469F2EC.7040508@andybierman.com>
In-Reply-To: <4469F2EC.7040508@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 May 2006 15:59:46.0925 (UTC) FILETIME=[C128E9D0:01C67901]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56

I don't see the connection between scaling and notification classes. Also if we manage to 
filter notifications that just improves scalability.

We need a notification template I agree but even if we just say
- we have event class filters
- xpath or subtree filters are applied to the data in the notification starting from a 
standard base point e.g. <data>

and leave the data model below this base point up to each implementation we still have 
produced something useful. Based on this you could build a model agnostic tool where 
filters can be configured on a GUI.

Still I feel the notification content should be defined in more detail. The notification 
draft does contain a very basic XSD for notifications (mainly page 23). Would you like a 
more detailed more specific XSD separately for each notification class or how would you 
start defining the event classes. I am willing to put in some work on this, but after 
understanding that you feel that the current version is insufficient I would like to 
understand what you would like to see in the draft.

regards Balazs

Andy Bierman wrote:
> Balazs Lengyel wrote:
>> Hello,
>> If we provided the following set of data for each notification(why 
>> event?) class would that be enough ?
> 
> I like the term notification classification better.
> 
> 
>> - Definition
>> - Events that trigger the notification
>> - Expected data, might contain optional parts
>> - expected handling/usage
>>
>> Or do we need more ? What ?
> 
> 
> We don't have any notification definition template for
> XSD, RelaxNG or whatever.  If one were to define such
> a template, there would be a field for the event-class.
> 
> We need a classification set that is complete and
> also easy to decide which classification to choose.
> Otherwise, standard filters based on event-type will be mostly worthless
> because no 2 agents classify notifications the same way.
> 
> Since this entire solution scales so poorly, without useful
> filtering for session-based manager ease-of-use, it is
> totally pointless.
> 
>>
>> Balazs
> 
> 
> Andy
> 
> 
>>
>> Andy Bierman wrote:
>>> Balazs Lengyel wrote:
>>>
>>> IMO, the only thing that matters here is that the
>>> classifications are clearly defined so that any
>>> 2 independent implementors will pick the same
>>> classification for the same new notification message.
>>>
>>> There is no way that can happen given the current text.
>>> The descriptions of some of them are too vague, and there
>>> is too much overlap.
>>>
>>> Andy
>>>
>>>
>>>> Hello
>>>> - FAULT event - OK, but could specify the details somewhat even if 
>>>> they are optional e.g. eventsource, probable cause,  severity, 
>>>> specific problem
>>>> - CONFIGURATION - OK
>>>> - STATE - OK
>>>> - AUDIT event seems a bit overkill. I think event classes should 
>>>> mainly speak about
>>>>     why/on what occasion do  we send that specific event class
>>>>     what information does an event class carry
>>>>     what handling is expected of the specific event class
>>>> Here we only have part of the third point. You could have an audit 
>>>> trail of state changes or a trail of configuration changes etc. I 
>>>> don't see this as a separate event class. It should be merged with 
>>>> something or removed.
>>>> - DATA DUMP event should me merged with configuration event. The 
>>>> main difference is that it can also carry state information. But 
>>>> thats already included in State event, so kill data dump.
>>>> - Ericsson needs MAINTENANCE events. See Jurgens requirement page: 
>>>> "notify about delayed results of long running RPCs [BL]". I am not 
>>>> totally happy with the name of the event class, but I like the idea 
>>>> behind it. If the draft misses this Ericsson will have to do some 
>>>> dirty workaround.
>>>> - METRICS is certainly out of scope although I don't see any real 
>>>> problem with it. We must note however that Netconf events are 
>>>> probably unsuitable for HIGH volume performance data transfer.
>>>> - HEART BEAT - OK
>>>> - INFORMATION event is really an extension mechanism. OK.
>>>> - SYSLOG: We spoke a lot about transferring syslog via events, but 
>>>> please could someone say who really has a requirement to do this! If 
>>>> we really have the requirement Jurgen please add it to your page!
>>>> - SECURITY - mentioned in the initial list, but not described later. 
>>>> As I see it security related notifications can be carried as fault 
>>>> or state events, so I don't see a need for this event class.
>>>>
>>>> Balazs
>>>>
>>>> Andy Bierman wrote:
>>>>> Hi,
>>>>>
>>>>> This section is very under-specified.
>>>>>
>>>>> IMO, it is impossible for independent developers
>>>>> to select classifications in an interoperable manner.
>>>>>
>>>>> It is really not at all clear why we need audit, data,
>>>>> maintenance, metrics, information, and syslog classes at all.
>>>>>
>>>>> Most of these are totally redundant.
>>>>>
>>>>> Metrics is out of scope.
>>>>>
>>>>> Syslog is not a proper member of this classification set.
>>>>> In XML, we use namespaces to identify content format,
>>>>> such as syslog/RAW, syslog/COOKED, acme/TOASTED, etc.
>>>>> The notification <data> section will be just like
>>>>> the <config> or <data> elements already defined in
>>>>> the protocol.
>>>>>
>>>>> 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: <http://ops.ietf.org/lists/netconf/>
>>>>
>>>>
>>>> -- 
>>>> to unsubscribe send a message to netconf-request@ops.ietf.org with
>>>> the word 'unsubscribe' in a single line as the message text body.
>>>> archive: <http://ops.ietf.org/lists/netconf/>
>>>>
>>>>
>>>
>>
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 16 12:26:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fg2No-0005zo-SG
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 12:26:52 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fg2Nl-0008NM-BL
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 12:26:52 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fg2J9-000CCc-FU
	for netconf-data@psg.com; Tue, 16 May 2006 16:22:03 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fg2J0-000CCF-7O
	for netconf@ops.ietf.org; Tue, 16 May 2006 16:21:54 +0000
Received: from mail.networksolutionsemail.com (ns-omr5.mgt.hosting.dc2.netsol.com [10.49.6.68])
	by ns-omrbm5.netsolmail.com (8.13.6/8.13.6) with SMTP id k4GGLpFj011398
	for <netconf@ops.ietf.org>; Tue, 16 May 2006 12:21:52 -0400
Received: (qmail 15660 invoked by uid 78); 16 May 2006 16:21:45 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.68 with SMTP; 16 May 2006 16:21:45 -0000
Message-ID: <4469FC10.4040506@andybierman.com>
Date: Tue, 16 May 2006 09:21:36 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: event classes (sec. 3.5)
References: <445B7A1C.9090803@andybierman.com> <4469E01A.9040604@ericsson.com> <4469EABF.9020301@andybierman.com> <4469ED45.6020103@ericsson.com> <4469F2EC.7040508@andybierman.com> <4469F6F1.8000008@ericsson.com>
In-Reply-To: <4469F6F1.8000008@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb

Balazs Lengyel wrote:
> I don't see the connection between scaling and notification classes. 
> Also if we manage to filter notifications that just improves scalability.


They are not.
I don't think this solution is suitable for replacing
any existing non-session based notification system.
Therefore (IMO) the only use it has is to copy and deliver netconf
specific notifications (over a session) while a manager is connected
for operations.

Even if one really wanted notifications over sessions, why not just
run syslog over ssh somehow?  It is not at all clear to me
why reinvented-syslog over netconf over ssh is important.



> 
> We need a notification template I agree but even if we just say
> - we have event class filters
> - xpath or subtree filters are applied to the data in the notification 
> starting from a standard base point e.g. <data>
> 
> and leave the data model below this base point up to each implementation 
> we still have produced something useful. Based on this you could build a 
> model agnostic tool where filters can be configured on a GUI.
> 
> Still I feel the notification content should be defined in more detail. 
> The notification draft does contain a very basic XSD for notifications 
> (mainly page 23). Would you like a more detailed more specific XSD 
> separately for each notification class or how would you start defining 
> the event classes. I am willing to put in some work on this, but after 
> understanding that you feel that the current version is insufficient I 
> would like to understand what you would like to see in the draft.


Look at an IANA classification system like interface type (ifType).
Without specific documentation to determine which classification
to choose, there is no point to standardizing the classification
system.

I already pointed out that this document does not actually need
to define the classification system.  At the protocol level,
the <event-class> could be a Name string.  But if it does
include a classification system, it must be complete, meet
IETF documentation standards, and show WG consensus for each
enumerated choice.


> 
> regards Balazs


Andy

> 
> Andy Bierman wrote:
>> Balazs Lengyel wrote:
>>> Hello,
>>> If we provided the following set of data for each notification(why 
>>> event?) class would that be enough ?
>>
>> I like the term notification classification better.
>>
>>
>>> - Definition
>>> - Events that trigger the notification
>>> - Expected data, might contain optional parts
>>> - expected handling/usage
>>>
>>> Or do we need more ? What ?
>>
>>
>> We don't have any notification definition template for
>> XSD, RelaxNG or whatever.  If one were to define such
>> a template, there would be a field for the event-class.
>>
>> We need a classification set that is complete and
>> also easy to decide which classification to choose.
>> Otherwise, standard filters based on event-type will be mostly worthless
>> because no 2 agents classify notifications the same way.
>>
>> Since this entire solution scales so poorly, without useful
>> filtering for session-based manager ease-of-use, it is
>> totally pointless.
>>
>>>
>>> Balazs
>>
>>
>> Andy
>>
>>
>>>
>>> Andy Bierman wrote:
>>>> Balazs Lengyel wrote:
>>>>
>>>> IMO, the only thing that matters here is that the
>>>> classifications are clearly defined so that any
>>>> 2 independent implementors will pick the same
>>>> classification for the same new notification message.
>>>>
>>>> There is no way that can happen given the current text.
>>>> The descriptions of some of them are too vague, and there
>>>> is too much overlap.
>>>>
>>>> Andy
>>>>
>>>>
>>>>> Hello
>>>>> - FAULT event - OK, but could specify the details somewhat even if 
>>>>> they are optional e.g. eventsource, probable cause,  severity, 
>>>>> specific problem
>>>>> - CONFIGURATION - OK
>>>>> - STATE - OK
>>>>> - AUDIT event seems a bit overkill. I think event classes should 
>>>>> mainly speak about
>>>>>     why/on what occasion do  we send that specific event class
>>>>>     what information does an event class carry
>>>>>     what handling is expected of the specific event class
>>>>> Here we only have part of the third point. You could have an audit 
>>>>> trail of state changes or a trail of configuration changes etc. I 
>>>>> don't see this as a separate event class. It should be merged with 
>>>>> something or removed.
>>>>> - DATA DUMP event should me merged with configuration event. The 
>>>>> main difference is that it can also carry state information. But 
>>>>> thats already included in State event, so kill data dump.
>>>>> - Ericsson needs MAINTENANCE events. See Jurgens requirement page: 
>>>>> "notify about delayed results of long running RPCs [BL]". I am not 
>>>>> totally happy with the name of the event class, but I like the idea 
>>>>> behind it. If the draft misses this Ericsson will have to do some 
>>>>> dirty workaround.
>>>>> - METRICS is certainly out of scope although I don't see any real 
>>>>> problem with it. We must note however that Netconf events are 
>>>>> probably unsuitable for HIGH volume performance data transfer.
>>>>> - HEART BEAT - OK
>>>>> - INFORMATION event is really an extension mechanism. OK.
>>>>> - SYSLOG: We spoke a lot about transferring syslog via events, but 
>>>>> please could someone say who really has a requirement to do this! 
>>>>> If we really have the requirement Jurgen please add it to your page!
>>>>> - SECURITY - mentioned in the initial list, but not described 
>>>>> later. As I see it security related notifications can be carried as 
>>>>> fault or state events, so I don't see a need for this event class.
>>>>>
>>>>> Balazs
>>>>>
>>>>> Andy Bierman wrote:
>>>>>> Hi,
>>>>>>
>>>>>> This section is very under-specified.
>>>>>>
>>>>>> IMO, it is impossible for independent developers
>>>>>> to select classifications in an interoperable manner.
>>>>>>
>>>>>> It is really not at all clear why we need audit, data,
>>>>>> maintenance, metrics, information, and syslog classes at all.
>>>>>>
>>>>>> Most of these are totally redundant.
>>>>>>
>>>>>> Metrics is out of scope.
>>>>>>
>>>>>> Syslog is not a proper member of this classification set.
>>>>>> In XML, we use namespaces to identify content format,
>>>>>> such as syslog/RAW, syslog/COOKED, acme/TOASTED, etc.
>>>>>> The notification <data> section will be just like
>>>>>> the <config> or <data> elements already defined in
>>>>>> the protocol.
>>>>>>
>>>>>> 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: <http://ops.ietf.org/lists/netconf/>
>>>>>
>>>>>
>>>>> -- 
>>>>> to unsubscribe send a message to netconf-request@ops.ietf.org with
>>>>> the word 'unsubscribe' in a single line as the message text body.
>>>>> archive: <http://ops.ietf.org/lists/netconf/>
>>>>>
>>>>>
>>>>
>>>
>>
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 16 12:54:39 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fg2oh-0006Nl-Gy
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 12:54:39 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fg2of-0001WW-2O
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 12:54:39 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fg2h3-000DpS-3u
	for netconf-data@psg.com; Tue, 16 May 2006 16:46:45 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fg2h1-000Dp5-7w
	for netconf@ops.ietf.org; Tue, 16 May 2006 16:46:44 +0000
Received: from mail.networksolutionsemail.com (ns-omr2.mgt.hosting.dc2.netsol.com [10.49.6.65])
	by ns-omrbm2.netsolmail.com (8.13.6/8.13.6) with SMTP id k4GGkgEn020471
	for <netconf@ops.ietf.org>; Tue, 16 May 2006 12:46:42 -0400
Received: (qmail 19747 invoked by uid 78); 16 May 2006 16:45:56 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 16 May 2006 16:45:56 -0000
Message-ID: <446A01BE.7050803@andybierman.com>
Date: Tue, 16 May 2006 09:45:50 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: Martin Bjorklund <mbj@tail-f.com>, netconf@ops.ietf.org
Subject: Re: nested operation attribute interoperability
References: <44691A34.8030608@andybierman.com>	<20060516.081906.64513942.mbj@tail-f.com>	<44699F75.7060800@andybierman.com> <20060516.122345.32981761.mbj@tail-f.com> <4469ED91.9040204@andybierman.com>
In-Reply-To: <4469ED91.9040204@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 093efd19b5f651b2707595638f6c4003

 >....
> 
> Also because there is no text whatsoever in the document
> that declares an error condition if 'replace' is invoked
> against an empty portion of the target config.
> 
> 

I was wrong.  There is some text.
The document is rather sloppy in this area.


Here is the operation attribute definition section [p. 37]:

          merge: The configuration data identified by the element
             containing this attribute is merged with the configuration
             at the corresponding level in the configuration datastore
             identified by the target parameter.  This is the default
             behavior.

          replace: The configuration data identified by the element
             containing this attribute replaces any related configuration
             in the configuration datastore identified by the target
             parameter.  Unlike a <copy-config> operation, which replaces
             the entire target configuration, only the configuration
             actually present in the config parameter is affected.

          create: The configuration data identified by the element
             containing this attribute is added to the configuration if
             and only if the configuration data does not already exist on
             the device.  If the configuration data exists, an <rpc-
             error> element is returned with an <error-tag> value of
             data-exists.

          delete: The configuration data identified by the element
             containing this attribute is deleted in the configuration
             datastore identified by the target parameter.


Note that only the 'create' operation defines an error condition here,
but Appendix A does say delete can cause an error.  It treats
replace and delete the same wrt/ data-missing error:


    Tag:         data-exists
    Error-type:  application
    Severity:    error
    Error-info:  none
    Description: Request could not be completed because the relevant
                 data model content already exists. For example,
                 a 'create' operation was attempted on data which
                 already exists.

    Tag:         data-missing
    Error-type:  application
    Severity:    error
    Error-info:  none
    Description: Request could not be completed because the relevant
                 data model content does not exist.  For example,
                 a 'replace' or 'delete' operation was attempted on
                 data which does not exist.

           *** IMO, the 2nd sentence above is wrong. ***


The text on pg 37 for 'replace' says:
             Unlike a <copy-config> operation, which replaces
             the entire target configuration, only the configuration
             actually present in the config parameter is affected.

The text for copy-config on pg 43 says:

       Create or replace an entire configuration datastore with the
       contents of another complete configuration datastore.  If the
       target datastore exists, it is overwritten.  Otherwise, a new one
       is created, if allowed.

Given the other definitions of 'create' and 'replace', this text
is rather confusing.


---------------------

History:

The WG started out with only merge and replace.
Merge was existing CLI behavior.
Replace was delete-if-it-exists, and then re-create it.
Replace was meant to simplify CLI like:
   no access-list 101
   access-list 101 ....

Then some WG members decided these 2 operations were not
sufficient precisely because they did not generate errors
in these corner-cases.  So we added create (only if it
does not exist) and delete (only if it exists).

I do not remember ever changing the definition of replace
to cause an error like delete.  I remember the opposite.
It is supposed to work like copy-config, except just
on the specified config subset.  IMO, the 2 words 'replace or'
in Appendix A are incorrect.




>>
>> Allowing create under a replace might make sense though, if we want to
>> be liberal.
>>
>> I'm happy to change this code to make it interopable.
>>
>>
>> /martin
> 
> 
> Andy


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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 16 12:57:00 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fg2qy-0007TE-5y
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 12:57:00 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fg2qw-0001aw-Sz
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 12:57:00 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fg2n8-000EDe-D2
	for netconf-data@psg.com; Tue, 16 May 2006 16:53:02 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1Fg2n6-000EDR-N9
	for netconf@ops.ietf.org; Tue, 16 May 2006 16:53:00 +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 k4GGqpX53707;
	Tue, 16 May 2006 09:52:51 -0700 (PDT)
	(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 k4GGqj577279;
	Tue, 16 May 2006 09:52:45 -0700 (PDT)
	(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 k4GGvpO4046926;
	Tue, 16 May 2006 12:57:52 -0400 (EDT)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200605161657.k4GGvpO4046926@idle.juniper.net>
To: Andy Bierman <ietf@andybierman.com>
cc: Martin Bjorklund <mbj@tail-f.com>, netconf@ops.ietf.org
Subject: Re: nested operation attribute interoperability 
In-Reply-To: Your message of "Tue, 16 May 2006 09:45:50 PDT."
             <446A01BE.7050803@andybierman.com> 
Date: Tue, 16 May 2006 12:57:51 -0400
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c

Andy Bierman writes:
>           *** IMO, the 2nd sentence above is wrong. ***
>I do not remember ever changing the definition of replace
>to cause an error like delete.  I remember the opposite.

This is my memory as well, and I concur that the 2nd sentence
is wrong.

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 16 13:50:26 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fg3gg-00068n-Go
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 13:50:26 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fg3ge-00043i-6f
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 13:50:26 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fg3cq-000Hls-Lj
	for netconf-data@psg.com; Tue, 16 May 2006 17:46:28 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fg3cp-000HlZ-EK
	for netconf@ops.ietf.org; Tue, 16 May 2006 17:46:28 +0000
Received: from mail.networksolutionsemail.com (ns-omr2.mgt.hosting.dc2.netsol.com [10.49.6.65])
	by ns-omrbm2.netsolmail.com (8.13.6/8.13.6) with SMTP id k4GHkPiL031245
	for <netconf@ops.ietf.org>; Tue, 16 May 2006 13:46:26 -0400
Received: (qmail 22072 invoked by uid 78); 16 May 2006 17:44:51 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 16 May 2006 17:44:51 -0000
Message-ID: <446A0F8C.1060502@andybierman.com>
Date: Tue, 16 May 2006 10:44:44 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: Martin Bjorklund <mbj@tail-f.com>, netconf@ops.ietf.org
Subject: Re: nested operation attribute interoperability
References: <200605161657.k4GGvpO4046926@idle.juniper.net>
In-Reply-To: <200605161657.k4GGvpO4046926@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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa

Phil Shafer wrote:
> Andy Bierman writes:
>>           *** IMO, the 2nd sentence above is wrong. ***
>> I do not remember ever changing the definition of replace
>> to cause an error like delete.  I remember the opposite.
> 
> This is my memory as well, and I concur that the 2nd sentence
> is wrong.

Here is an 'operational sniff test':

Let's say I want to delete all the <user> entries,
but I don't want to remove the <users> container.
Otherwise the purpose of the container is lost.
(OK -- I would probably not really be deleting the user table ;-)

The default-operation parameter for the <edit-config> operation
is set to 'none', although any value actually works in
this example.

1) This causes an error if <users> is already empty

    <users>
       <user operation="delete"/>
    </users>

2) This does not cause an error if <users> is already empty
    and it is simpler to encode:

    <users operation="replace"/>

Both mechanisms should be supported, and they are if 'replace'
is interpreted as originally intended.


> 
> 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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 16 14:41:26 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fg4U2-0004Ge-Fi
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 14:41:26 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fg4U0-0005yY-Ur
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 14:41:26 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fg4PI-000LEb-Ow
	for netconf-data@psg.com; Tue, 16 May 2006 18:36:32 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1Fg4PH-000LEQ-QT
	for netconf@ops.ietf.org; Tue, 16 May 2006 18:36:32 +0000
Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id 59F0C40;
	Tue, 16 May 2006 20:36:30 +0200 (CEST)
Date: Tue, 16 May 2006 20:36:19 +0200 (CEST)
Message-Id: <20060516.203619.16403606.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: netconf@ops.ietf.org
Subject: Re: nested operation attribute interoperability
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4469ED91.9040204@andybierman.com>
References: <44699F75.7060800@andybierman.com>
	<20060516.122345.32981761.mbj@tail-f.com>
	<4469ED91.9040204@andybierman.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a

Andy Bierman <ietf@andybierman.com> wrote:
> Martin Bjorklund wrote:
> > Andy Bierman <ietf@andybierman.com> wrote:
> >>> child ->  create   merge   replace   delete
> >>> parent
> >>>     |
> >>>  
> >>>    none      V        V        V         V
> >>>  
> >>>   create     x        V-1      E-1(*)    E-1
> >>>
> >>>   merge      V-3      x        V-4(*)    V-3    
> >>>
> >>>   replace    E-1(*)   V        x         E-1(*)
> >>>
> >>>   delete     E-1      V-2      E-1(*)    x
> >>>
> >>>
> >>>> Notes:
> >>>>
> >>>> V:    valid, no errors or warnings
> >>>>
> >>>> V-1:  valid, but create has precedence.
> >>>>       Only merge-with-nothing or replace-nothing scenarios are valid.
> >>>>
> >>>> V-2:  valid, but has no effect because delete has precedence
> >>>>
> >>>> V-3:  valid, but create or delete rules now in affect for next child
> >>>>
> >>>> E-1:  'bad-attribute' or 'operation-failed' error (not sure which)
> >>>>       Requirements for create and delete cannot both be met
> >>>>       in the same subtree, regardless of the data model
> 
> 
> Both these error codes are wrong for my E-1.
> This is clearly a 'data-exists' error.
>
> There is no way you could get to <b> in the example
> below unless <a> existed, which violates the 'create' rules.
> 
> edit-config <config> contents
> ------------------------------
> 
> <a operation="create">
>    <b operation="replace"/>
> </a>
> 
> 
> Current Config          Result
> ------------------------------
> empty                   ok
> <a/>                    data-exists error
> <a><b/></a>             data-exists error


Ah... got it.  We would actually also generate a data-exist error in
this case (if <a> doesn't exist).

Suppose <a/> exists.  Then comes:

<a operation="delete">
   <b operation="merge"/>
</a>

What would the result be?



/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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 16 15:10:11 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fg4vr-0004ys-Dw
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 15:10:11 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fg4vp-00082t-0W
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 15:10:11 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fg4rP-000NT8-ON
	for netconf-data@psg.com; Tue, 16 May 2006 19:05:35 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fg4rP-000NSu-1R
	for netconf@ops.ietf.org; Tue, 16 May 2006 19:05:35 +0000
Received: from mail.networksolutionsemail.com (ns-omr5.mgt.hosting.dc2.netsol.com [10.49.6.68])
	by ns-omrbm5.netsolmail.com (8.13.6/8.13.6) with SMTP id k4GJ5T2q003365
	for <netconf@ops.ietf.org>; Tue, 16 May 2006 15:05:31 -0400
Received: (qmail 15828 invoked by uid 78); 16 May 2006 19:05:29 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.68 with SMTP; 16 May 2006 19:05:29 -0000
Message-ID: <446A226F.4000301@andybierman.com>
Date: Tue, 16 May 2006 12:05:19 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC: netconf@ops.ietf.org
Subject: Re: nested operation attribute interoperability
References: <44699F75.7060800@andybierman.com>	<20060516.122345.32981761.mbj@tail-f.com>	<4469ED91.9040204@andybierman.com> <20060516.203619.16403606.mbj@tail-f.com>
In-Reply-To: <20060516.203619.16403606.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>> Martin Bjorklund wrote:
>>> Andy Bierman <ietf@andybierman.com> wrote:
>>>>> child ->  create   merge   replace   delete
>>>>> parent
>>>>>     |
>>>>>  
>>>>>    none      V        V        V         V
>>>>>  
>>>>>   create     x        V-1      E-1(*)    E-1
>>>>>
>>>>>   merge      V-3      x        V-4(*)    V-3    
>>>>>
>>>>>   replace    E-1(*)   V        x         E-1(*)
>>>>>
>>>>>   delete     E-1      V-2      E-1(*)    x
>>>>>
>>>>>
>>>>>> Notes:
>>>>>>
>>>>>> V:    valid, no errors or warnings
>>>>>>
>>>>>> V-1:  valid, but create has precedence.
>>>>>>       Only merge-with-nothing or replace-nothing scenarios are valid.
>>>>>>
>>>>>> V-2:  valid, but has no effect because delete has precedence
>>>>>>
>>>>>> V-3:  valid, but create or delete rules now in affect for next child
>>>>>>
>>>>>> E-1:  'bad-attribute' or 'operation-failed' error (not sure which)
>>>>>>       Requirements for create and delete cannot both be met
>>>>>>       in the same subtree, regardless of the data model
>>
>> Both these error codes are wrong for my E-1.
>> This is clearly a 'data-exists' error.
>>
>> There is no way you could get to <b> in the example
>> below unless <a> existed, which violates the 'create' rules.
>>
>> edit-config <config> contents
>> ------------------------------
>>
>> <a operation="create">
>>    <b operation="replace"/>
>> </a>
>>
>>
>> Current Config          Result
>> ------------------------------
>> empty                   ok
>> <a/>                    data-exists error
>> <a><b/></a>             data-exists error
> 
> 
> Ah... got it.  We would actually also generate a data-exist error in
> this case (if <a> doesn't exist).
> 
> Suppose <a/> exists.  Then comes:
> 
> <a operation="delete">
>    <b operation="merge"/>
> </a>
> 
> What would the result be?
> 
> 

Hmmm... I think I see your point.
If I apply the delete test to <b> before fully
processing <b>, then I will generate a data-missing
error (if <b> does not yet exist).  But if I process
the nodes fully, bottom up, then <b> always exists when the
delete-test is performed and there is no error.
But this is much harder then processing nodes top-down.
This is also pointless since <a operation="delete"/>
will provide the same functionality.

The result should be no error and <a> is deleted,
but I could also see how a data-missing error
could be generated instead.



> 
> /martin

Andy

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 16 15:20:20 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fg55g-0007wT-0W
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 15:20:20 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fg55c-0008VQ-LU
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 15:20:19 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fg51P-000O9R-2u
	for netconf-data@psg.com; Tue, 16 May 2006 19:15:55 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1Fg51N-000O9C-R7
	for netconf@ops.ietf.org; Tue, 16 May 2006 19:15:54 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4GJFnm11787
	for <netconf@ops.ietf.org>; Tue, 16 May 2006 15:15:50 -0400 (EDT)
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: Verbiage
Date: Tue, 16 May 2006 15:15:48 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4087C28BE@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Verbiage
Thread-Index: AcZ45k/Xj0at/HsTSJ2n0yD1tS4myQANpWIg
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc

hi

Note that named profiles are not filters in the latest draft. While in
earlier drafts they were holders for proprietary filtering methods, now
they are only a mechanism to save a favourite set of filters. So,
really, there is only one mechanisms.

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Balazs Lengyel
Sent: Tuesday, May 16, 2006 8:30 AM
To: Netconf (E-mail)
Subject: Re: Verbiage


Hello,
I am more disturbed by the fact that we have two filter mechanism -
named profile and=20
filter in the draft. These seem really to do the same thing one using a
data model while=20
the other trying to conform to a verb type solution.

Please merge the two! You could kill the filter or say that it updates
the stored=20
filter/named profile.


Myself I am more on the data model side but can we settle for Andy's
compromise: Set up what to do using a data model then start/stop
subscription using a very simple=20
verb/operation?

regards Balazs

Sharon Chisholm wrote:
> hi
>=20
> <Andy>
>=20
> I think you missed a key point in this thread.
> New RPCs are appropriate when they don't
> replicate the existing RPCs.  Several WG members
> are not convinced at all that subscription data
> is anything other than config data.
>=20
> </Andy>
>=20
> No, I don't think I did.  I thought people raised some very good=20
> points to consider when deciding whether or not to add new verbs. Just

> whether existing verbs and a chunk of data model *could* be used=20
> obviously isn't the only criteria or we wouldn't have a made some of=20
> the decisions we made in the base protocol.
>=20
> Usability by the client and ease of integration into the network=20
> itself need to also be considered.
>=20
> Sharon
>=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: <http://ops.ietf.org/lists/netconf/>

--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

--
to unsubscribe send a message to netconf-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 16 15:36:20 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fg5LA-0004oS-Fh
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 15:36:20 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fg5L9-0001SF-5n
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 15:36:20 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fg5Gm-000PJo-Iv
	for netconf-data@psg.com; Tue, 16 May 2006 19:31:48 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1Fg5Gk-000PJY-Tk
	for netconf@ops.ietf.org; Tue, 16 May 2006 19:31:47 +0000
Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id 0626240;
	Tue, 16 May 2006 21:31:46 +0200 (CEST)
Date: Tue, 16 May 2006 21:31:35 +0200 (CEST)
Message-Id: <20060516.213135.106602188.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: netconf@ops.ietf.org
Subject: Re: nested operation attribute interoperability
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <446A226F.4000301@andybierman.com>
References: <4469ED91.9040204@andybierman.com>
	<20060516.203619.16403606.mbj@tail-f.com>
	<446A226F.4000301@andybierman.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9


I agree that top-down processing makes most sense (that's what we do
today). 

So, what should the table be?  Like this maybe

child ->  create   merge   replace   delete
parent
  |

 none      V        V        V         V

create     x        V        V         E-1

merge      V        x        V         V

replace    V        V        x         E-1

delete     E-1      V        E-1       x


The E-1 on delete under replace would be motivated by the fact that
replace is first delete, then create.  So it should give the same
error as delete under create.

The only question mark is maybe the last row.   Why should merge under
delete be allowed?  (maybe for convenience; default operation is
'merge', and with this you can do:

   <user operation="delete">
      <name>fred</name>
   </user>

to delete the fred user, if <name> is used as key.)



/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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 16 17:56:16 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fg7Wa-0007G8-AQ
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 17:56:16 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fg7WW-0001b4-Oo
	for netconf-archive@lists.ietf.org; Tue, 16 May 2006 17:56:16 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fg7RE-0008q0-Pr
	for netconf-data@psg.com; Tue, 16 May 2006 21:50:44 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fg7RB-0008ph-Uc
	for netconf@ops.ietf.org; Tue, 16 May 2006 21:50:42 +0000
Received: from mail.networksolutionsemail.com (ns-omr6.mgt.hosting.dc2.netsol.com [10.49.6.69])
	by ns-omrbm6.netsolmail.com (8.13.6/8.13.6) with SMTP id k4GLof3Z015461
	for <netconf@ops.ietf.org>; Tue, 16 May 2006 17:50:41 -0400
Received: (qmail 27150 invoked by uid 78); 16 May 2006 21:50:41 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.69 with SMTP; 16 May 2006 21:50:41 -0000
Message-ID: <446A4926.2050704@andybierman.com>
Date: Tue, 16 May 2006 14:50:30 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC: netconf@ops.ietf.org
Subject: Re: nested operation attribute interoperability
References: <4469ED91.9040204@andybierman.com>	<20060516.203619.16403606.mbj@tail-f.com>	<446A226F.4000301@andybierman.com> <20060516.213135.106602188.mbj@tail-f.com>
In-Reply-To: <20060516.213135.106602188.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168

Martin Bjorklund wrote:
> I agree that top-down processing makes most sense (that's what we do
> today). 
> 

Let's approach the problem that way.
Let's remember (I didn't) that it is the contents
of the target configuration that matters, not the
child nodes within the PDU request, when testing the
edit operation for the current node.


> So, what should the table be?  Like this maybe
> 
> child ->  create   merge   replace   delete
> parent
>   |
> 
>  none      V        V        V         V
> 
> create     x        V        V         E-1
> 
> merge      V        x        V         V
> 
> replace    V        V        x         E-1
> 
> delete     E-1      V        E-1       x

merge and replace are not really different in these nesting cases.
Your E-1 for replace-delete and delete-replace seem wrong
because there is no existence test for replace.


> 
> 
> The E-1 on delete under replace would be motivated by the fact that
> replace is first delete, then create.  So it should give the same
> error as delete under create.
> 
> The only question mark is maybe the last row.   Why should merge under
> delete be allowed?  (maybe for convenience; default operation is
> 'merge', and with this you can do:
> 
>    <user operation="delete">
>       <name>fred</name>
>    </user>


No -- operations affect the current node and all its children.
The operation for <name> is 'delete'.

Top-down processing works:
If there are no <user> nodes in the target data model, then it
doesn't matter if <name> is present or not -- it is still a
data-missing error as soon as <user> is processed.

Since the operation in effect at the next node is a delete on the
selection node 'fred', if the <user> node did exist, but the entry
for 'fred' did not exist, the delete test for name=fred fails,
and a data-missing error is correctly generated.

If you really did have:

<user operation="delete">
    <name operation="replace">fred</name>
</user>

This 'replace' would be a NO-OP (V-2 as I interpreted it).
Since 'replace' and 'merge' do not have existence test errors,
there is no error generated even if the 'replace' attribute
is processed.  The end result is that the target data model
is deleted, starting from the node that 'delete' is first seen.
(Further processing for selection nodes is required of course.)




> 
> to delete the fred user, if <name> is used as key.)
> 
> 
> 
> /martin


Andy


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 17 04:08:43 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgH5H-0000ly-7n
	for netconf-archive@lists.ietf.org; Wed, 17 May 2006 04:08:43 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FgH5G-0007fV-JE
	for netconf-archive@lists.ietf.org; Wed, 17 May 2006 04:08:43 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FgGsn-000DJg-P0
	for netconf-data@psg.com; Wed, 17 May 2006 07:55:49 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FgGsl-000DJO-If
	for netconf@ops.ietf.org; Wed, 17 May 2006 07:55:47 +0000
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4B4B04F0105;
	Wed, 17 May 2006 09:55:46 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 17 May 2006 09:55:46 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 17 May 2006 09:55:45 +0200
Message-ID: <446AD701.6030509@ericsson.com>
Date: Wed, 17 May 2006 09:55:45 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Verbiage
References: <713043CE8B8E1348AF3C546DBE02C1B4087C28BE@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4087C28BE@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 May 2006 07:55:46.0008 (UTC) FILETIME=[4DD66580:01C67987]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745

Hello,
But if we can point out a stored filter then why do we need to define a second filter 
inline in the subscription/modify-subscription request ? Why don't we just define the 
filter referenced by the named profile and use it in the subscription request ? It would 
make the world simpler. Do we really so strongly need filters that are alive only for a 
session that we need to complicate the operation ?
Balazs

Sharon Chisholm wrote:
> hi
> 
> Note that named profiles are not filters in the latest draft. While in
> earlier drafts they were holders for proprietary filtering methods, now
> they are only a mechanism to save a favourite set of filters. So,
> really, there is only one mechanisms.
> 
> Sharon
> 
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
> Behalf Of Balazs Lengyel
> Sent: Tuesday, May 16, 2006 8:30 AM
> To: Netconf (E-mail)
> Subject: Re: Verbiage
> 
> 
> Hello,
> I am more disturbed by the fact that we have two filter mechanism -
> named profile and 
> filter in the draft. These seem really to do the same thing one using a
> data model while 
> the other trying to conform to a verb type solution.
> 
> Please merge the two! You could kill the filter or say that it updates
> the stored 
> filter/named profile.
> 
> 
> Myself I am more on the data model side but can we settle for Andy's
> compromise: Set up what to do using a data model then start/stop
> subscription using a very simple 
> verb/operation?
> 
> regards Balazs
> 
> Sharon Chisholm wrote:
>> hi
>>
>> <Andy>
>>
>> I think you missed a key point in this thread.
>> New RPCs are appropriate when they don't
>> replicate the existing RPCs.  Several WG members
>> are not convinced at all that subscription data
>> is anything other than config data.
>>
>> </Andy>
>>
>> No, I don't think I did.  I thought people raised some very good 
>> points to consider when deciding whether or not to add new verbs. Just
> 
>> whether existing verbs and a chunk of data model *could* be used 
>> obviously isn't the only criteria or we wouldn't have a made some of 
>> the decisions we made in the base protocol.
>>
>> Usability by the client and ease of integration into the network 
>> itself need to also be considered.
>>
>> 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: <http://ops.ietf.org/lists/netconf/>
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 17 04:34:51 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgHUZ-00019Y-Bo
	for netconf-archive@lists.ietf.org; Wed, 17 May 2006 04:34:51 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FgHUW-0000Q0-Si
	for netconf-archive@lists.ietf.org; Wed, 17 May 2006 04:34:51 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FgHOR-000FND-C4
	for netconf-data@psg.com; Wed, 17 May 2006 08:28:31 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FgHOQ-000FN1-49
	for netconf@ops.ietf.org; Wed, 17 May 2006 08:28:30 +0000
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3C7C76AE
	for <netconf@ops.ietf.org>; Wed, 17 May 2006 10:28:29 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 17 May 2006 10:28:29 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 17 May 2006 10:28:28 +0200
Message-ID: <446ADEAC.7030003@ericsson.com>
Date: Wed, 17 May 2006 10:28:28 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: CallHome Notifications
References: <713043CE8B8E1348AF3C546DBE02C1B4086CC04C@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4086CC04C@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 May 2006 08:28:28.0982 (UTC) FILETIME=[DFDC7560:01C6798B]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb

Hello,
Once a call-home session is established what is the reason that it is less reliable then 
the subscription based notifications ?

Why do the call-home session need to be short lived ?

(I agree that if the network manager is down or it's address is incorrect etc. then we 
will not get any notifications.)
Balazs

Sharon Chisholm wrote:
> hi
> 
> This capability was added after there seemed to be working group
> consensus that it was needed. The specification explicitly states that
> it doesn't provide reliable delivery of notifications since I think it
> makes sense to state up front what isn't supported in this alternative
> method so that we don't have to spend a lot of cycles trying to get
> parity with the main subscription method.
> 
> 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: <http://ops.ietf.org/lists/netconf/>
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 17 05:01:57 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgHun-0002Xn-88
	for netconf-archive@lists.ietf.org; Wed, 17 May 2006 05:01:57 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FgHum-0003J3-Nw
	for netconf-archive@lists.ietf.org; Wed, 17 May 2006 05:01:57 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FgHpA-000HIK-Av
	for netconf-data@psg.com; Wed, 17 May 2006 08:56:08 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FgHp8-000HI4-MM
	for netconf@ops.ietf.org; Wed, 17 May 2006 08:56:07 +0000
Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id 5B59240;
	Wed, 17 May 2006 10:56:05 +0200 (CEST)
Date: Wed, 17 May 2006 10:55:54 +0200 (CEST)
Message-Id: <20060517.105554.103206073.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: netconf@ops.ietf.org
Subject: Re: nested operation attribute interoperability
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <446A4926.2050704@andybierman.com>
References: <446A226F.4000301@andybierman.com>
	<20060516.213135.106602188.mbj@tail-f.com>
	<446A4926.2050704@andybierman.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7

Andy Bierman <ietf@andybierman.com> wrote:
> Martin Bjorklund wrote:
> > I agree that top-down processing makes most sense (that's what we do
> > today). 
> > 
> 
> Let's approach the problem that way.
> Let's remember (I didn't) that it is the contents
> of the target configuration that matters, not the
> child nodes within the PDU request, when testing the
> edit operation for the current node.
> 
> 
> > So, what should the table be?  Like this maybe
> > 
> > child ->  create   merge   replace   delete
> > parent
> >   |
> > 
> >  none      V        V        V         V
> > 
> > create     x        V        V         E-1
> > 
> > merge      V        x        V         V
> > 
> > replace    V        V        x         E-1
> > 
> > delete     E-1      V        E-1       x
> 
> merge and replace are not really different in these nesting cases.
> Your E-1 for replace-delete and delete-replace seem wrong
> because there is no existence test for replace.

If replace-delete is interpreted as "first replace parent. then, while
doing the replace, delete the child", the "delete the child" will fail
with data-missing.

delete-replace... first delete the parent, then replace the child.  If
this does not generate an error, the child would actually be created.
Same goes for delete-merge if this interpretation is used.  So maybe
an error should be generated even for delete-merge.


> > The E-1 on delete under replace would be motivated by the fact that
> > replace is first delete, then create.  So it should give the same
> > error as delete under create.
> > 
> > The only question mark is maybe the last row.   Why should merge under
> > delete be allowed?  (maybe for convenience; default operation is
> > 'merge', and with this you can do:
> > 
> >    <user operation="delete">
> >       <name>fred</name>
> >    </user>
> 
> 
> No -- operations affect the current node and all its children.
> The operation for <name> is 'delete'.

You're right.

(But is this obvious from the text?  Is it this sentence from 7.2 that
defines this behaviour:

    The attribute identifies the point in the configuration to perform
    the operation,
)


> Top-down processing works:
> If there are no <user> nodes in the target data model, then it
> doesn't matter if <name> is present or not -- it is still a
> data-missing error as soon as <user> is processed.
> 
> Since the operation in effect at the next node is a delete on the
> selection node 'fred', if the <user> node did exist, but the entry
> for 'fred' did not exist, the delete test for name=fred fails,
> and a data-missing error is correctly generated.
> 
> If you really did have:
> 
> <user operation="delete">
>     <name operation="replace">fred</name>
> </user>
> 
> This 'replace' would be a NO-OP (V-2 as I interpreted it).
> Since 'replace' and 'merge' do not have existence test errors,
> there is no error generated even if the 'replace' attribute
> is processed.  The end result is that the target data model
> is deleted, starting from the node that 'delete' is first seen.
> (Further processing for selection nodes is required of course.)

But this must also depend on the data model.

If name is key in user, this would delete the user fred:

<user operation="delete">
    <name>fred</name>
</user>

But this wouldn't delete all admin users, would it? 

<user operation="delete">
    <type>admin</type>
</user>

Unless you apply some kind of subtree filtering semantics on the
delete.


/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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 17 12:39:40 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgP3k-0000kb-Ic
	for netconf-archive@lists.ietf.org; Wed, 17 May 2006 12:39:40 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FgP3h-0001qs-Tk
	for netconf-archive@lists.ietf.org; Wed, 17 May 2006 12:39:40 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FgOvr-00007b-Og
	for netconf-data@psg.com; Wed, 17 May 2006 16:31:31 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FgOvp-00007M-V4
	for netconf@ops.ietf.org; Wed, 17 May 2006 16:31:30 +0000
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DCE7862D
	for <netconf@ops.ietf.org>; Wed, 17 May 2006 18:31:23 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 17 May 2006 18:31:23 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 17 May 2006 18:31:23 +0200
Message-ID: <446B4FDB.6000102@ericsson.com>
Date: Wed, 17 May 2006 18:31:23 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: The datamodel in Notification Draft
References: <713043CE8B8E1348AF3C546DBE02C1B4086CC037@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4086CC037@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 May 2006 16:31:23.0616 (UTC) FILETIME=[5616BE00:01C679CF]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5

Hello,
Some comments to Andy's model:
We need the concept of "Ongoing Notification Session" (subscription in the draft)
We need this as we do not want to open a new session for each notification for each 
target. We need to store the existing sessionId and reuse it.

- target port missing, even if we have a default I believe it is generally a good idea to 
allow ports to be configured
- target transport missing (SSH, BEEP, SOAP)
- target:mixed or separate session
- I think using meaningful names are better then just using an arbitrary integer as index. 
I see this as one of the selling points for Netconf. I would propose the following that 
profileindex and filterindex should be strings, maybe the parameter should be profilename, 
filtername
- target and filter shall somehow be linked. When we want a callback you need to know 
which profile to use
- target: should the sessionId of existing sessions be included ?
- with this model ANDY you implicitly seem to accept that eventclass will be part of every 
event, correct ?

About filters:
Data should include eventclasses, xpath, subtree
Today we/Ericsson are using proprietary filters like
(eventclass1 && xpath) || (eventclass2 && xpath && xpath) || eventclass3
where xpath can be exchanged for a subtree filter. However this is impossible in both 
versions. Actually it would be enough to have one xpath/subtree filter for each eventclass.


Balazs

--------------------------------------

My personal view on modeling OPTIONAL reading only:
We need to model the following entities:
- Ongoing Notification Session (subscription in the draft)
We need this as we do not want to open a new session for each notification for each 
target. We need to store the existing sessionId and reuse it.
- Filter
- Target (callHomeSubscription in the draft)
- Profile (is it needed ?)

We need to link a target both to a filter and an ongoing session. I imagine the Netconf 
agent would work like this:
1) Event occurs
2) agent scans the list of targets
3) for each target it checks against the related filters
4) If they block the notification goto next target
5) Filters allows notification; check if it has an existing session,
		if yes goto 7
6) If no session open a new session to target
7) We have an existing session; send notification on session, goto next target

Targets would be created by normal configuration commands (maybe just before subscribing.
SessionId for a target will be set when creating a new call-home session or by the 
subscribe operation during the existing session

The above discussion misses mixed versus separate session transport as yet.


Sharon Chisholm wrote:
> hi
> 
> A few bits of clarification after reading through the discussions.
> 
> 1. Named profiles in the latest version of the draft are fully specified
> in the XML Schema provided. This allows for persistency of subscription
> information, just not the actual subscription. The callHome capability
> does allow for this persistency though.
> 
> 2. The information model that Andy sent out didn't seem that different
> from what is in the draft already. I believe these were the differences
> 	- It wasn't specified in XML Schema
> 	- It used the term table as appose to elements
>       - It had an arbitrary index instead of using sessionId and
> subscriptionID
> 	- It better specified the subscriber. As Balasz pointed out, the
> current draft if not sufficiently prescriptive. Subscriber is only a
> string.
> 
> 3. I think it would be good if we could look at defining minAccess and
> maxAccess in a machine-readable form to publish in parallel with this
> document. Failing that, I guess we have no choice but to fall back using
> the documentation tag.
> 
> 
> 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: <http://ops.ietf.org/lists/netconf/>
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 17 13:30:31 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgPqx-0005cC-Qi
	for netconf-archive@lists.ietf.org; Wed, 17 May 2006 13:30:31 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FgPqx-0004FO-AF
	for netconf-archive@lists.ietf.org; Wed, 17 May 2006 13:30:31 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FgPjq-0004AY-Ay
	for netconf-data@psg.com; Wed, 17 May 2006 17:23:10 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FgPjo-0004AM-Q5
	for netconf@ops.ietf.org; Wed, 17 May 2006 17:23:08 +0000
Received: from mail.networksolutionsemail.com (ns-omr3.mgt.hosting.dc2.netsol.com [10.49.6.66])
	by ns-omrbm3.netsolmail.com (8.13.6/8.13.6) with SMTP id k4HHN7Mp025984
	for <netconf@ops.ietf.org>; Wed, 17 May 2006 13:23:07 -0400
Received: (qmail 26805 invoked by uid 78); 17 May 2006 17:23:07 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.66 with SMTP; 17 May 2006 17:23:07 -0000
Message-ID: <446B5BF5.5040102@andybierman.com>
Date: Wed, 17 May 2006 10:23:01 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: The datamodel in Notification Draft
References: <713043CE8B8E1348AF3C546DBE02C1B4086CC037@zcarhxm2.corp.nortel.com> <446B4FDB.6000102@ericsson.com>
In-Reply-To: <446B4FDB.6000102@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 200d029292fbb60d25b263122ced50fc

Balazs Lengyel wrote:
> Hello,
> Some comments to Andy's model:
> We need the concept of "Ongoing Notification Session" (subscription in 
> the draft)
> We need this as we do not want to open a new session for each 
> notification for each target. We need to store the existing sessionId 
> and reuse it.


IMO, there isn't any session-based notification system
that makes sense.  We should not reinvent UDP
based notification architecture with some hack to
get around the overhead of sessions.

The notion of a session that exists even if the other
peer in the session does not exist -- is extremely broken.
Is this what you mean by "ongoing session"?

The subscription mechanism requires a manager to reenter
the filter data every time a new session is started.
This is somehow perceived as easier to use.  Supposedly
a <create-subscription> RPC is much less complex than
an <edit-config> RPC.  All the examples in the draft indicate
that the filter element is much more complicated than any of the
<edit-config> parameters, and the <filter> would be the same either way.



> 
> - target port missing, even if we have a default I believe it is 
> generally a good idea to allow ports to be configured
> - target transport missing (SSH, BEEP, SOAP)
> - target:mixed or separate session
> - I think using meaningful names are better then just using an arbitrary 
> integer as index. I see this as one of the selling points for Netconf. I 
> would propose the following that profileindex and filterindex should be 
> strings, maybe the parameter should be profilename, filtername
> - target and filter shall somehow be linked. When we want a callback you 
> need to know which profile to use
> - target: should the sessionId of existing sessions be included ?
> - with this model ANDY you implicitly seem to accept that eventclass 
> will be part of every event, correct ?


EventClass should be part of the notification header.
The <data> field in each notification should be identified
by a namespace, just like we do with the <config> element.


> 
> About filters:
> Data should include eventclasses, xpath, subtree
> Today we/Ericsson are using proprietary filters like
> (eventclass1 && xpath) || (eventclass2 && xpath && xpath) || eventclass3
> where xpath can be exchanged for a subtree filter. However this is 
> impossible in both versions. Actually it would be enough to have one 
> xpath/subtree filter for each eventclass.


I'm not convinced that anything in this entire feature is economically
viable.  It seems to be a way to move complex code from 1 manager
to 1000s of agents.  I don't believe many vendors
will abandon their investment in syslog and use this instead.


> 
> 
> Balazs

Andy

> 
> --------------------------------------
> 
> My personal view on modeling OPTIONAL reading only:
> We need to model the following entities:
> - Ongoing Notification Session (subscription in the draft)
> We need this as we do not want to open a new session for each 
> notification for each target. We need to store the existing sessionId 
> and reuse it.
> - Filter
> - Target (callHomeSubscription in the draft)
> - Profile (is it needed ?)
> 
> We need to link a target both to a filter and an ongoing session. I 
> imagine the Netconf agent would work like this:
> 1) Event occurs
> 2) agent scans the list of targets
> 3) for each target it checks against the related filters
> 4) If they block the notification goto next target
> 5) Filters allows notification; check if it has an existing session,
>         if yes goto 7
> 6) If no session open a new session to target
> 7) We have an existing session; send notification on session, goto next 
> target
> 
> Targets would be created by normal configuration commands (maybe just 
> before subscribing.
> SessionId for a target will be set when creating a new call-home session 
> or by the subscribe operation during the existing session
> 
> The above discussion misses mixed versus separate session transport as yet.
> 
> 
> Sharon Chisholm wrote:
>> hi
>>
>> A few bits of clarification after reading through the discussions.
>>
>> 1. Named profiles in the latest version of the draft are fully specified
>> in the XML Schema provided. This allows for persistency of subscription
>> information, just not the actual subscription. The callHome capability
>> does allow for this persistency though.
>>
>> 2. The information model that Andy sent out didn't seem that different
>> from what is in the draft already. I believe these were the differences
>>     - It wasn't specified in XML Schema
>>     - It used the term table as appose to elements
>>       - It had an arbitrary index instead of using sessionId and
>> subscriptionID
>>     - It better specified the subscriber. As Balasz pointed out, the
>> current draft if not sufficiently prescriptive. Subscriber is only a
>> string.
>>
>> 3. I think it would be good if we could look at defining minAccess and
>> maxAccess in a machine-readable form to publish in parallel with this
>> document. Failing that, I guess we have no choice but to fall back using
>> the documentation tag.
>>
>>
>> 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: <http://ops.ietf.org/lists/netconf/>
>>
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 17 16:57:46 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgT5W-0005HW-Jn
	for netconf-archive@lists.ietf.org; Wed, 17 May 2006 16:57:46 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FgT5U-0001hx-48
	for netconf-archive@lists.ietf.org; Wed, 17 May 2006 16:57:46 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FgSzI-000JrG-Up
	for netconf-data@psg.com; Wed, 17 May 2006 20:51:20 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FgSzG-000Jqn-CZ
	for netconf@ops.ietf.org; Wed, 17 May 2006 20:51:18 +0000
Received: from mail.networksolutionsemail.com (ns-omr3.mgt.hosting.dc2.netsol.com [10.49.6.66])
	by ns-omrbm3.netsolmail.com (8.13.6/8.13.6) with SMTP id k4HKpHPM020198
	for <netconf@ops.ietf.org>; Wed, 17 May 2006 16:51:17 -0400
Received: (qmail 21182 invoked by uid 78); 17 May 2006 20:51:17 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.66 with SMTP; 17 May 2006 20:51:17 -0000
Message-ID: <446B8CBF.5070805@andybierman.com>
Date: Wed, 17 May 2006 13:51:11 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC: netconf@ops.ietf.org
Subject: Re: nested operation attribute interoperability
References: <446A226F.4000301@andybierman.com>	<20060516.213135.106602188.mbj@tail-f.com>	<446A4926.2050704@andybierman.com> <20060517.105554.103206073.mbj@tail-f.com>
In-Reply-To: <20060517.105554.103206073.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>> Martin Bjorklund wrote:
>>> I agree that top-down processing makes most sense (that's what we do
>>> today). 
>>>
>> Let's approach the problem that way.
>> Let's remember (I didn't) that it is the contents
>> of the target configuration that matters, not the
>> child nodes within the PDU request, when testing the
>> edit operation for the current node.
>>
>>
>>> So, what should the table be?  Like this maybe
>>>
>>> child ->  create   merge   replace   delete
>>> parent
>>>   |
>>>
>>>  none      V        V        V         V
>>>
>>> create     x        V        V         E-1
>>>
>>> merge      V        x        V         V
>>>
>>> replace    V        V        x         E-1
>>>
>>> delete     E-1      V        E-1       x
>> merge and replace are not really different in these nesting cases.
>> Your E-1 for replace-delete and delete-replace seem wrong
>> because there is no existence test for replace.
> 
> If replace-delete is interpreted as "first replace parent. then, while
> doing the replace, delete the child", the "delete the child" will fail
> with data-missing.
> 
> delete-replace... first delete the parent, then replace the child.  If
> this does not generate an error, the child would actually be created.
> Same goes for delete-merge if this interpretation is used.  So maybe
> an error should be generated even for delete-merge.

1) only 'create' and 'delete' have any kind of existence tests.
    Merge and replace can always work and never generate an error because
    of data present or missing in the target configuration.

2) The 'create' and 'delete' tests apply to the target data models,
    not to the content of the edit-config PDU.  The test is not done
    against the PDU at all.  Doing the tests bottom-up will not change
    anything, because the target data models have not been modified yet.

3) Any operations under a 'delete' within the PDU are academic.
    They only serve to complicate test-suites, and have no operational
    value.  What matters is the state the target config when you are done.
    If an operation to delete <foo> is going to succeed, then
    the 'activity' in the PDU for children of <foo> is irrelevant.
    (Although not to the error reporting rules.)




> 
> 
>>> The E-1 on delete under replace would be motivated by the fact that
>>> replace is first delete, then create.  So it should give the same
>>> error as delete under create.
>>>
>>> The only question mark is maybe the last row.   Why should merge under
>>> delete be allowed?  (maybe for convenience; default operation is
>>> 'merge', and with this you can do:
>>>
>>>    <user operation="delete">
>>>       <name>fred</name>
>>>    </user>
>>
>> No -- operations affect the current node and all its children.
>> The operation for <name> is 'delete'.
> 
> You're right.
> 
> (But is this obvious from the text?  Is it this sentence from 7.2 that
> defines this behaviour:
> 
>     The attribute identifies the point in the configuration to perform
>     the operation,
> )
> 
> 
>> Top-down processing works:
>> If there are no <user> nodes in the target data model, then it
>> doesn't matter if <name> is present or not -- it is still a
>> data-missing error as soon as <user> is processed.
>>
>> Since the operation in effect at the next node is a delete on the
>> selection node 'fred', if the <user> node did exist, but the entry
>> for 'fred' did not exist, the delete test for name=fred fails,
>> and a data-missing error is correctly generated.
>>
>> If you really did have:
>>
>> <user operation="delete">
>>     <name operation="replace">fred</name>
>> </user>
>>
>> This 'replace' would be a NO-OP (V-2 as I interpreted it).
>> Since 'replace' and 'merge' do not have existence test errors,
>> there is no error generated even if the 'replace' attribute
>> is processed.  The end result is that the target data model
>> is deleted, starting from the node that 'delete' is first seen.
>> (Further processing for selection nodes is required of course.)
> 
> But this must also depend on the data model.
> 
> If name is key in user, this would delete the user fred:
> 
> <user operation="delete">
>     <name>fred</name>
> </user>
> 
> But this wouldn't delete all admin users, would it? 


There is nothing in the protocol that actually says the
construct above means "delete the entry named fred".
Your agent just has to know to look for the naming elements
if the NMS is deleting multiple-instanced nodes this way.


> 
> <user operation="delete">
>     <type>admin</type>
> </user>
> 
> Unless you apply some kind of subtree filtering semantics on the
> delete.

There are no data modeling rules yet, so you can experiment
and figure out what works best.  I don't see why you couldn't
do something like this.  However, this is not a subtree filter,
and the agent is not obliged to treat it as one.

I was the one who originally pushed hard against the idea
of multiple operation attributes in the <config> subtree, because
I knew there were many more unintended consequences than
benefits in this design approach.

I think you were the one that suggested using xpath expressions
instead of these subtrees. E.g.,

  <rpc>
    <delete target="/users/user[name='fred']"/>
  </rpc>

I am starting to think it would be easier to constrain xpath
than the subtree approach, in order to minimize the dev-effort required
to properly report corner-case errors, and reduce the number
of operationally worthless corner-cases.



> 
> 
> /martin

Andy



--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 17 18:17:01 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgUKD-0003vy-UC
	for netconf-archive@lists.ietf.org; Wed, 17 May 2006 18:17:01 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FgUKD-0006hN-FU
	for netconf-archive@lists.ietf.org; Wed, 17 May 2006 18:17:01 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FgUFS-000PPQ-43
	for netconf-data@psg.com; Wed, 17 May 2006 22:12:06 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FgUFR-000PPF-4f
	for netconf@ops.ietf.org; Wed, 17 May 2006 22:12:05 +0000
Received: from mail.networksolutionsemail.com (ns-omr5.mgt.hosting.dc2.netsol.com [10.49.6.68])
	by ns-omrbm5.netsolmail.com (8.13.6/8.13.6) with SMTP id k4HMC4F3026696
	for <netconf@ops.ietf.org>; Wed, 17 May 2006 18:12:04 -0400
Received: (qmail 14137 invoked by uid 78); 17 May 2006 22:12:04 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.68 with SMTP; 17 May 2006 22:12:04 -0000
Message-ID: <446B9FAB.2050402@andybierman.com>
Date: Wed, 17 May 2006 15:11:55 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: event classes (sec. 3.5)
References: <445B7A1C.9090803@andybierman.com> <4469E01A.9040604@ericsson.com>
In-Reply-To: <4469E01A.9040604@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f

Balazs Lengyel wrote:
>....
> - Ericsson needs MAINTENANCE events. See Jurgens requirement page: 
> "notify about delayed results of long running RPCs [BL]". I am not 
> totally happy with the name of the event class, but I like the idea 
> behind it. If the draft misses this Ericsson will have to do some dirty 
> workaround.

I think this delayed <rpc-reply> should have its own event class
and fully defined syntax (because it's already done in the prot-spec).

This could turn out to be an important feature.
IMO, a specialized RPC to provide 'ping' type of exec
features is a good use of session-specific config.
and netconf-specific session-based notifications.

E.g.:

  <rpc message-id="101">
    <ping>
      <source>
      <target>
      <frequency>60</frequency>
      <rest-of-ping-params ...>
    </ping>
   </rpc>

   <rpc-reply  message-id="101">
     <ok/>
   </rpc-reply>

   ... 60 seconds later

   <notification>
     <event-class>rpc-reply</event-class>
     <sequence-id>42</sequence-id>
     <data>
       <rpc-reply message-id="101">
         ...  ping result # 1
       </rpc-reply>
     </data>
   </notification>

  ... 60 seconds later

   <notification>
     <event-class>rpc-reply</event-class>
     <sequence-id>43</sequence-id>
     <data>
       <rpc-reply message-id="101">
         ...  ping result # 2
       </rpc-reply>
     </data>
   </notification>



> - METRICS is certainly out of scope although I don't see any real 
> problem with it. We must note however that Netconf events are probably 
> unsuitable for HIGH volume performance data transfer.


The problem with it is that netconf is chartered
for a completely different purpose.  The ipfix protocol
is designed much more appropriately for streaming metrics
data from source to sink.  They made very different design
choices than netconf because they are solving a different
problem.  Streaming metrics data encoded in XML over a session
over TCP seems rather inefficient to me.


> - HEART BEAT - OK
> - INFORMATION event is really an extension mechanism. OK.

why not call it 'other' then?

> - SYSLOG: We spoke a lot about transferring syslog via events, but 
> please could someone say who really has a requirement to do this! If we 
> really have the requirement Jurgen please add it to your page!

IMO syslog is not an event classification at all
and does not belong in the set, unless it indicates
the exact content of the payload (like my rpc-reply event class.)
Is is syslog/RAW or syslog/COOKED or something else?
If I need to depend on the namespace URIs in the data anyway,
then what value is this classification?

I agree with you that it doesn't make a lot of sense
to tunnel syslog over netconf, but from a dev-cost POV,
it would be easy to implement syslog/RAW over netconf.
It would provide no additional value whatsoever from a modeling
perspective, but maybe it does from a transport and
security perspective.



> - SECURITY - mentioned in the initial list, but not described later. As 
> I see it security related notifications can be carried as fault or state 
> events, so I don't see a need for this event class.
> 

agreed

> Balazs


Andy



> 
> Andy Bierman wrote:
>> Hi,
>>
>> This section is very under-specified.
>>
>> IMO, it is impossible for independent developers
>> to select classifications in an interoperable manner.
>>
>> It is really not at all clear why we need audit, data,
>> maintenance, metrics, information, and syslog classes at all.
>>
>> Most of these are totally redundant.
>>
>> Metrics is out of scope.
>>
>> Syslog is not a proper member of this classification set.
>> In XML, we use namespaces to identify content format,
>> such as syslog/RAW, syslog/COOKED, acme/TOASTED, etc.
>> The notification <data> section will be just like
>> the <config> or <data> elements already defined in
>> the protocol.
>>
>> 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: <http://ops.ietf.org/lists/netconf/>
> 
> 
> -- 
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 18 07:25:42 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FggdS-0001TJ-Mf
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 07:25:42 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FggdM-0002KW-1P
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 07:25:42 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FggUg-000B9b-DD
	for netconf-data@psg.com; Thu, 18 May 2006 11:16:38 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FggUe-000B9K-FV
	for netconf@ops.ietf.org; Thu, 18 May 2006 11:16:36 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4D6474F0001;
	Thu, 18 May 2006 13:16:35 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 18 May 2006 13:16:35 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 18 May 2006 13:16:34 +0200
Message-ID: <446C5792.6050306@ericsson.com>
Date: Thu, 18 May 2006 13:16:34 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: The datamodel in Notification Draft
References: <713043CE8B8E1348AF3C546DBE02C1B4086CC037@zcarhxm2.corp.nortel.com> <446B4FDB.6000102@ericsson.com> <446B5BF5.5040102@andybierman.com>
In-Reply-To: <446B5BF5.5040102@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 May 2006 11:16:34.0938 (UTC) FILETIME=[85F8F5A0:01C67A6C]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745

Hello Andy,
I might not really get your point.

MY point was: I do not want to go through the Netconf session set-up for each notification 
the node wants to send. This would mean session overhead, authentication overhead etc. 
This is why I say you need to hold on to and reuse the ongoing session. Even SNMP is 
moving towards session based security with ISMS as I understand.

As I understand, you on the other hand want to set up a new session and re-authenticate 
for each notification? Or did I misunderstand you?

Andy Bierman wrote:
> Balazs Lengyel wrote:
>> Hello,
>> Some comments to Andy's model:
>> We need the concept of "Ongoing Notification Session" (subscription in 
>> the draft)
>> We need this as we do not want to open a new session for each 
>> notification for each target. We need to store the existing sessionId 
>> and reuse it.
> 
> 
> IMO, there isn't any session-based notification system
> that makes sense.  We should not reinvent UDP
> based notification architecture with some hack to
> get around the overhead of sessions.
> 
> The notion of a session that exists even if the other
> peer in the session does not exist -- is extremely broken.
> Is this what you mean by "ongoing session"?

NO. But if the other end does not exists (callHome) the node tries to set up a session to 
it. If the peer really doesn't exist the session setup fails the notification will not be 
sent. But if the peer exists just the session between the manager and the agent is missing 
the agent should be able to rebuild it.
> 
> The subscription mechanism requires a manager to reenter
> the filter data every time a new session is started.
> This is somehow perceived as easier to use.  Supposedly
> a <create-subscription> RPC is much less complex than
> an <edit-config> RPC.  All the examples in the draft indicate
> that the filter element is much more complicated than any of the
> <edit-config> parameters, and the <filter> would be the same either way.

I see our solution (and my optional part) serves both callhome and subscription. The 
manager/agent will be free to choose the between the two methods. IMHO whether we reuse an 
ongoing session (as above) or not is independent from the method we used to set it up: 
subscription or callhome.

-------------------------------------------------------------------

Balazs Lengyel's personal view on modeling OPTIONAL reading only:
We need to model the following entities:
- Ongoing Notification Session
We need this as we do not want to open a new session for each notification for each 
target. We need to store the existing session id and reuse it.
- Filter
- Target (callHomeSubscription in the draft)
- Profile (is it needed ?)

We need to link a target both to a filter and an ongoing session. I imagine the Netconf 
agent would work like this:
1) Event occurs
2) agent scans the list of targets
3) for each target it checks against the related filters
4) If they block the notification goto next target
5) Filters allows notification; check if it has an existing session,
         if yes goto 7
6) If no session; open a new session to target
7) We have an existing session; send notification on session, goto next target

Targets would be created by normal configuration commands e.g. <edit-config>. These can be 
issued once and data will be used for a long time or you could use <edit-config> ; 
<subscribe> ; <unsubscribe> ; <edit-config : operation:delete> for short lived subscriptions.

SessionId for a target will be set when creating a new call-home session or by the 
subscribe operation during the existing session

The above discussion misses mixed versus separate session transport as yet.

---------------------------------------------------------------------


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 18 07:50:07 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fgh15-00036l-Rv
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 07:50:07 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fgh14-00057x-IE
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 07:50:07 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FggwU-000CkR-8X
	for netconf-data@psg.com; Thu, 18 May 2006 11:45:22 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FggwT-000Ck7-6w
	for netconf@ops.ietf.org; Thu, 18 May 2006 11:45:21 +0000
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5B4144F0001
	for <netconf@ops.ietf.org>; Thu, 18 May 2006 13:45:20 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 18 May 2006 13:45:19 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 18 May 2006 13:45:19 +0200
Message-ID: <446C5E4E.4020803@ericsson.com>
Date: Thu, 18 May 2006 13:45:18 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Scalability as requirement
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 May 2006 11:45:19.0176 (UTC) FILETIME=[89B2CC80:01C67A70]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89

Jurgen,
Could you please add scalability to your requirements page. After the discussions I 
believe we require that the protocol should allow 30.000 to 100.000 nodes to send 
notifications to a management station and the station should be able to order the 100.000 
nodes to send the notifications.
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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 18 07:56:46 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fgh7W-0005nf-SP
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 07:56:46 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fgh7U-0005aO-Ac
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 07:56:46 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fgh2h-000DEB-8v
	for netconf-data@psg.com; Thu, 18 May 2006 11:51:47 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fgh2g-000DDw-3A
	for netconf@ops.ietf.org; Thu, 18 May 2006 11:51:46 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.hosting.dc2.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k4IBpjxr006192
	for <netconf@ops.ietf.org>; Thu, 18 May 2006 07:51:45 -0400
Received: (qmail 28908 invoked by uid 78); 18 May 2006 11:51:45 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 18 May 2006 11:51:45 -0000
Message-ID: <446C5FBB.70801@andybierman.com>
Date: Thu, 18 May 2006 04:51:23 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: The datamodel in Notification Draft
References: <713043CE8B8E1348AF3C546DBE02C1B4086CC037@zcarhxm2.corp.nortel.com> <446B4FDB.6000102@ericsson.com> <446B5BF5.5040102@andybierman.com> <446C5792.6050306@ericsson.com>
In-Reply-To: <446C5792.6050306@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3

Balazs Lengyel wrote:
> Hello Andy,
> I might not really get your point.
> 
> MY point was: I do not want to go through the Netconf session set-up for 
> each notification the node wants to send. This would mean session 
> overhead, authentication overhead etc. This is why I say you need to 
> hold on to and reuse the ongoing session. Even SNMP is moving towards 
> session based security with ISMS as I understand.
> 
> As I understand, you on the other hand want to set up a new session and 
> re-authenticate for each notification? Or did I misunderstand you?


I am not convinced that netconf session-based notifications will
be used instead of syslog UDP-based notifications in operational
networks.   I'm not sure the overhead of auth/no-priv is more
than the overhead of session maintenance, but I am sure that
the manager-starts-notifications-via-subscription does not
scale well to large numbers of devices -- the initial notification
gap will be unacceptable in customer networks.


> 
> Andy Bierman wrote:
>> Balazs Lengyel wrote:
>>> Hello,
>>> Some comments to Andy's model:
>>> We need the concept of "Ongoing Notification Session" (subscription 
>>> in the draft)
>>> We need this as we do not want to open a new session for each 
>>> notification for each target. We need to store the existing sessionId 
>>> and reuse it.
>>
>>
>> IMO, there isn't any session-based notification system
>> that makes sense.  We should not reinvent UDP
>> based notification architecture with some hack to
>> get around the overhead of sessions.
>>
>> The notion of a session that exists even if the other
>> peer in the session does not exist -- is extremely broken.
>> Is this what you mean by "ongoing session"?
> 
> NO. But if the other end does not exists (callHome) the node tries to 
> set up a session to it. If the peer really doesn't exist the session 
> setup fails the notification will not be sent. But if the peer exists 
> just the session between the manager and the agent is missing the agent 
> should be able to rebuild it.


This is significantly more complex than the traditional
NV-configured fire-and-forget UDP-based notification systems.
If any part of the "use-UDP-instead-of-TCP when the network
is unstable" doctrine is still true, then it is for fault
notifications.


>>
>> The subscription mechanism requires a manager to reenter
>> the filter data every time a new session is started.
>> This is somehow perceived as easier to use.  Supposedly
>> a <create-subscription> RPC is much less complex than
>> an <edit-config> RPC.  All the examples in the draft indicate
>> that the filter element is much more complicated than any of the
>> <edit-config> parameters, and the <filter> would be the same either way.
> 
> I see our solution (and my optional part) serves both callhome and 
> subscription. The manager/agent will be free to choose the between the 
> two methods. IMHO whether we reuse an ongoing session (as above) or not 
> is independent from the method we used to set it up: subscription or 
> callhome.
> 
> -------------------------------------------------------------------
> 
> Balazs Lengyel's personal view on modeling OPTIONAL reading only:
> We need to model the following entities:
> - Ongoing Notification Session
> We need this as we do not want to open a new session for each 
> notification for each target. We need to store the existing session id 
> and reuse it.
> - Filter
> - Target (callHomeSubscription in the draft)
> - Profile (is it needed ?)
> 
> We need to link a target both to a filter and an ongoing session. I 
> imagine the Netconf agent would work like this:
> 1) Event occurs
> 2) agent scans the list of targets
> 3) for each target it checks against the related filters
> 4) If they block the notification goto next target
> 5) Filters allows notification; check if it has an existing session,
>         if yes goto 7
> 6) If no session; open a new session to target
> 7) We have an existing session; send notification on session, goto next 
> target
> 
> Targets would be created by normal configuration commands e.g. 
> <edit-config>. These can be issued once and data will be used for a long 
> time or you could use <edit-config> ; <subscribe> ; <unsubscribe> ; 
> <edit-config : operation:delete> for short lived subscriptions.
> 
> SessionId for a target will be set when creating a new call-home session 
> or by the subscribe operation during the existing session
> 
> The above discussion misses mixed versus separate session transport as yet.
> 
> ---------------------------------------------------------------------
> 
> 
> 


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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 18 08:06:20 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FghGm-0008VY-Rr
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 08:06:20 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FghGk-0005vL-8z
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 08:06:20 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FghAg-000Dsi-4t
	for netconf-data@psg.com; Thu, 18 May 2006 12:00:02 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FghAe-000DsB-Pk
	for netconf@ops.ietf.org; Thu, 18 May 2006 12:00:01 +0000
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DF4904F0003;
	Thu, 18 May 2006 13:59:59 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 18 May 2006 13:59:59 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 18 May 2006 13:59:59 +0200
Message-ID: <446C61BE.6060709@ericsson.com>
Date: Thu, 18 May 2006 13:59:58 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: The datamodel in Notification Draft
References: <713043CE8B8E1348AF3C546DBE02C1B4086CC037@zcarhxm2.corp.nortel.com> <446B4FDB.6000102@ericsson.com> <446B5BF5.5040102@andybierman.com> <446C5792.6050306@ericsson.com> <446C5FBB.70801@andybierman.com>
In-Reply-To: <446C5FBB.70801@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 May 2006 11:59:59.0545 (UTC) FILETIME=[96707290:01C67A72]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336

>> Andy Bierman wrote:
>>> Balazs Lengyel wrote:
>>>> Hello,
>>>> Some comments to Andy's model:
>>>> We need the concept of "Ongoing Notification Session" (subscription 
>>>> in the draft)
>>>> We need this as we do not want to open a new session for each 
>>>> notification for each target. We need to store the existing 
>>>> sessionId and reuse it.
>>>
>>>
>>> IMO, there isn't any session-based notification system
>>> that makes sense.  We should not reinvent UDP
>>> based notification architecture with some hack to
>>> get around the overhead of sessions.
>>>
>>> The notion of a session that exists even if the other
>>> peer in the session does not exist -- is extremely broken.
>>> Is this what you mean by "ongoing session"?
>>
>> NO. But if the other end does not exists (callHome) the node tries to 
>> set up a session to it. If the peer really doesn't exist the session 
>> setup fails the notification will not be sent. But if the peer exists 
>> just the session between the manager and the agent is missing the 
>> agent should be able to rebuild it.
> 
> 
> This is significantly more complex than the traditional
> NV-configured fire-and-forget UDP-based notification systems.
> If any part of the "use-UDP-instead-of-TCP when the network
> is unstable" doctrine is still true, then it is for fault
> notifications.

Currently we have 3 transport SSH, BEEP and SOAP so UDP would be something new. Do you 
suggest we should go for UDP or what is your proposal ?

For mixed notification sessions we anyway need to maintain the session.

JURGEN! Could you tell us how ISMS is solving the session based security?
As I understand they also decided to have proper security you need to maintain sessions.

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 18 08:23:18 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FghXC-00077O-6d
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 08:23:18 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FghXB-0006tE-Hl
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 08:23:18 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FghTR-000FIW-IJ
	for netconf-data@psg.com; Thu, 18 May 2006 12:19:25 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FghTP-000FIG-Vs
	for netconf@ops.ietf.org; Thu, 18 May 2006 12:19:24 +0000
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F1C914F004F;
	Thu, 18 May 2006 14:19:22 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 18 May 2006 14:19:22 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 18 May 2006 14:19:22 +0200
Message-ID: <446C6649.4070004@ericsson.com>
Date: Thu, 18 May 2006 14:19:21 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: event classes (sec. 3.5)
References: <445B7A1C.9090803@andybierman.com> <4469E01A.9040604@ericsson.com> <446B9FAB.2050402@andybierman.com>
In-Reply-To: <446B9FAB.2050402@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 May 2006 12:19:22.0307 (UTC) FILETIME=[4B7FD930:01C67A75]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48

Hello,
In Ericsson every managed object (conceptually similar to an XML element) can have both 
data (children) and associated actions. These are commands whose primary aim is NOT to set 
data but to do something like your ping. The possible actions are part of the data model 
so we only need one extra operation like <execute-action with parameters>.

As netconf is missing this feature we intended to do a workaround but I would be much more 
happy to see this in netconf itself. I just didn't bring it up as yet as there were so 
many other topics to discuss.

I wonder how Juniper solved this? They had Junos-script and operational mode commands like 
ping for a long time.

Balazs

Andy Bierman wrote:
> Balazs Lengyel wrote:
>> ....
>> - Ericsson needs MAINTENANCE events. See Jurgens requirement page: 
>> "notify about delayed results of long running RPCs [BL]". I am not 
>> totally happy with the name of the event class, but I like the idea 
>> behind it. If the draft misses this Ericsson will have to do some 
>> dirty workaround.
> 
> I think this delayed <rpc-reply> should have its own event class
> and fully defined syntax (because it's already done in the prot-spec).
> 
> This could turn out to be an important feature.
> IMO, a specialized RPC to provide 'ping' type of exec
> features is a good use of session-specific config.
> and netconf-specific session-based notifications.
> 
> E.g.:
> 
>  <rpc message-id="101">
>    <ping>
>      <source>
>      <target>
>      <frequency>60</frequency>
>      <rest-of-ping-params ...>
>    </ping>
>   </rpc>
> 
>   <rpc-reply  message-id="101">
>     <ok/>
>   </rpc-reply>
> 
>   ... 60 seconds later
> 
>   <notification>
>     <event-class>rpc-reply</event-class>
>     <sequence-id>42</sequence-id>
>     <data>
>       <rpc-reply message-id="101">
>         ...  ping result # 1
>       </rpc-reply>
>     </data>
>   </notification>
> 
>  ... 60 seconds later
> 
>   <notification>
>     <event-class>rpc-reply</event-class>
>     <sequence-id>43</sequence-id>
>     <data>
>       <rpc-reply message-id="101">
>         ...  ping result # 2
>       </rpc-reply>
>     </data>
>   </notification>
> 
> 
> 
>> - METRICS is certainly out of scope although I don't see any real 
>> problem with it. We must note however that Netconf events are probably 
>> unsuitable for HIGH volume performance data transfer.
> 
> 
> The problem with it is that netconf is chartered
> for a completely different purpose.  The ipfix protocol
> is designed much more appropriately for streaming metrics
> data from source to sink.  They made very different design
> choices than netconf because they are solving a different
> problem.  Streaming metrics data encoded in XML over a session
> over TCP seems rather inefficient to me.
> 
> 
>> - HEART BEAT - OK
>> - INFORMATION event is really an extension mechanism. OK.
> 
> why not call it 'other' then?
> 
>> - SYSLOG: We spoke a lot about transferring syslog via events, but 
>> please could someone say who really has a requirement to do this! If 
>> we really have the requirement Jurgen please add it to your page!
> 
> IMO syslog is not an event classification at all
> and does not belong in the set, unless it indicates
> the exact content of the payload (like my rpc-reply event class.)
> Is is syslog/RAW or syslog/COOKED or something else?
> If I need to depend on the namespace URIs in the data anyway,
> then what value is this classification?
> 
> I agree with you that it doesn't make a lot of sense
> to tunnel syslog over netconf, but from a dev-cost POV,
> it would be easy to implement syslog/RAW over netconf.
> It would provide no additional value whatsoever from a modeling
> perspective, but maybe it does from a transport and
> security perspective.
> 
> 
> 
>> - SECURITY - mentioned in the initial list, but not described later. 
>> As I see it security related notifications can be carried as fault or 
>> state events, so I don't see a need for this event class.
>>
> 
> agreed
> 
>> Balazs
> 
> 
> Andy
> 
> 
> 
>>
>> Andy Bierman wrote:
>>> Hi,
>>>
>>> This section is very under-specified.
>>>
>>> IMO, it is impossible for independent developers
>>> to select classifications in an interoperable manner.
>>>
>>> It is really not at all clear why we need audit, data,
>>> maintenance, metrics, information, and syslog classes at all.
>>>
>>> Most of these are totally redundant.
>>>
>>> Metrics is out of scope.
>>>
>>> Syslog is not a proper member of this classification set.
>>> In XML, we use namespaces to identify content format,
>>> such as syslog/RAW, syslog/COOKED, acme/TOASTED, etc.
>>> The notification <data> section will be just like
>>> the <config> or <data> elements already defined in
>>> the protocol.
>>>
>>> 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: <http://ops.ietf.org/lists/netconf/>
>>
>>
>> -- 
>> to unsubscribe send a message to netconf-request@ops.ietf.org with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
>>
>>
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 18 08:50:30 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FghxW-0007mD-El
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 08:50:30 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FghxW-0007tq-DI
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 08:50:30 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1Fghlz-0002QZ-Bb
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 08:38:38 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FghiS-000GKr-8l
	for netconf-data@psg.com; Thu, 18 May 2006 12:34:56 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FghiQ-000GKQ-3P
	for netconf@ops.ietf.org; Thu, 18 May 2006 12:34:54 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 4F4B15609D;
	Thu, 18 May 2006 14:34:53 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024)
 with ESMTP id 24749-08; Thu, 18 May 2006 14:34:51 +0200 (CEST)
Received: from boskop.local (unknown [10.222.1.3])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id 43E9A56095;
	Thu, 18 May 2006 14:34:51 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id E84976E1571; Thu, 18 May 2006 14:34:48 +0200 (CEST)
Date: Thu, 18 May 2006 14:34:48 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
Cc: Andy Bierman <ietf@andybierman.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: The datamodel in Notification Draft
Message-ID: <20060518123448.GA8261@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Balazs Lengyel <balazs.lengyel@ericsson.com>,
	Andy Bierman <ietf@andybierman.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
References: <713043CE8B8E1348AF3C546DBE02C1B4086CC037@zcarhxm2.corp.nortel.com> <446B4FDB.6000102@ericsson.com> <446B5BF5.5040102@andybierman.com> <446C5792.6050306@ericsson.com> <446C5FBB.70801@andybierman.com> <446C61BE.6060709@ericsson.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <446C61BE.6060709@ericsson.com>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -1.3 (-)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081

On Thu, May 18, 2006 at 01:59:58PM +0200, Balazs Lengyel wrote:
 
> JURGEN! Could you tell us how ISMS is solving the session based security?
> As I understand they also decided to have proper security you need to 
> maintain sessions.

ISMS is all about using existing security solutions for SNMP. It turns
out that the most widely deployed security solutions are somehow
session based and the most widely deployed onces are running over
TCP. Note that session based security is not the same as running over
TCP.

The statement "to have proper security you need to maintain sessions"
per se might not be correct. But to have security, you need to
maintain some state between the communicating endpoints and setting
this up involves some work, even in the case of SNMPv3/USM.

We will soon post some measurement data to the ISMS list which shows
the cost of the various transport and security options for SNMP. We
did the measurements on a perfect network but also under conditions of
packet loss. All I can say is that those who use a stock net-snmp
implementation really should not worry about a TCP transport in case
the network is in trouble. With other SNMP stacks you might be better
off - we did not measure them.

/js

PS: Also SNMPv3/USM has some overhead when you send the first
    notification and you have to synchronize clocks. You do not establish
    a session key which saves on round trip times, but also reduces
    the level of security you get if you are paranoid (or you have to
    do more frequent key changes). The point is that you have to look
    at the whole system and that it is misleading to separate out
    pieces of the picture and to look at it in isolation.

PPS: Even if you consider signed syslog messages over plain UDP, it might
     be instructive to figure out what the overall performance will be
     end-to-end including generation and verification of the
     signatures.

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 18 08:50:39 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fghxf-0007q9-AW
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 08:50:39 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fghxf-0007v0-8v
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 08:50:39 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1Fghjp-0002NW-Pm
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 08:36:24 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fghf0-000G6e-CP
	for netconf-data@psg.com; Thu, 18 May 2006 12:31:22 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1Fghez-000G6R-Oj
	for netconf@ops.ietf.org; Thu, 18 May 2006 12:31:21 +0000
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D56464F0053;
	Thu, 18 May 2006 14:31:20 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 18 May 2006 14:31:20 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 18 May 2006 14:31:20 +0200
Message-ID: <446C6917.2000603@ericsson.com>
Date: Thu, 18 May 2006 14:31:19 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: The datamodel in Notification Draft
References: <713043CE8B8E1348AF3C546DBE02C1B4086CC037@zcarhxm2.corp.nortel.com> <446B4FDB.6000102@ericsson.com> <446B5BF5.5040102@andybierman.com> <446C5792.6050306@ericsson.com> <446C5FBB.70801@andybierman.com> <446C61BE.6060709@ericsson.com> <446C639A.1000506@andybierman.com>
In-Reply-To: <446C639A.1000506@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 May 2006 12:31:20.0610 (UTC) FILETIME=[F7A43020:01C67A76]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.6 (--)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a

Hello,

Andy Bierman wrote:
>>
>> Currently we have 3 transport SSH, BEEP and SOAP so UDP would be 
>> something new. Do you suggest we should go for UDP or what is your 
>> proposal ?
> 
> 
> No -- you are missing my point.
> I am not convinced that netconf is an appropriate protocol
> to replace the functionality of syslog.  I would just
> use syslog if I wanted a notification system that scales.
> If I wanted a nice-to-have feature to make NMS netconf dev-work
> a little easier, I would consider using netconf notifications.
> 
> 
OK I would say let's kick out syslog (I don't need it). For other event classes would you 
like to have long life sessions with session maintenance and reuse or session set up for 
every notification or ???
I go with Sharon who opted for reuse in the draft.

Balazs

PS. For me the non-syslog part is really important not just nice-to-have.

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 18 08:55:32 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fgi2O-0000O1-Nu
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 08:55:32 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fgi2O-00088V-8y
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 08:55:32 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fghxx-000HZw-Tn
	for netconf-data@psg.com; Thu, 18 May 2006 12:50:57 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fghxw-000HZY-Kd
	for netconf@ops.ietf.org; Thu, 18 May 2006 12:50:56 +0000
Received: from mail.networksolutionsemail.com (ns-omr3.mgt.hosting.dc2.netsol.com [10.49.6.66])
	by ns-omrbm3.netsolmail.com (8.13.6/8.13.6) with SMTP id k4ICotXJ020056
	for <netconf@ops.ietf.org>; Thu, 18 May 2006 08:50:55 -0400
Received: (qmail 32442 invoked by uid 78); 18 May 2006 12:50:55 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.66 with SMTP; 18 May 2006 12:50:55 -0000
Message-ID: <446C6D90.8090009@andybierman.com>
Date: Thu, 18 May 2006 05:50:24 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: event classes (sec. 3.5)
References: <445B7A1C.9090803@andybierman.com> <4469E01A.9040604@ericsson.com> <446B9FAB.2050402@andybierman.com> <446C636E.1030600@ericsson.com>
In-Reply-To: <446C636E.1030600@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c

Balazs Lengyel wrote:
> I was extremely glad to read you mail !!!!
> - By the way we have a similar multiple reply feature called 
> "one-to-many exchange" in BEEP as well so the concept is not new.
> - On the other hand Sharon's definition includes automatic maintenance 
> action. Let's say we have a daily automatic backup and I want a 
> notification that it succeeded. Which event class would you choose for 
> this ?

MAINTENANCE

(I never said take this classification away.)

I think delayed rpc-reply messages are a more valid
reason for supporting mixed-mode (operations and notifications)
than saving 1 session overhead worth of memory in the NMS.


> 
> Balazs

Andy

> 
> 
> Andy Bierman wrote:
>> Balazs Lengyel wrote:
>>> ....
>>> - Ericsson needs MAINTENANCE events. See Jurgens requirement page: 
>>> "notify about delayed results of long running RPCs [BL]". I am not 
>>> totally happy with the name of the event class, but I like the idea 
>>> behind it. If the draft misses this Ericsson will have to do some 
>>> dirty workaround.
>>
>> I think this delayed <rpc-reply> should have its own event class
>> and fully defined syntax (because it's already done in the prot-spec).
>>
>> This could turn out to be an important feature.
>> IMO, a specialized RPC to provide 'ping' type of exec
>> features is a good use of session-specific config.
>> and netconf-specific session-based notifications.
>>
>> E.g.:
>>
>>  <rpc message-id="101">
>>    <ping>
>>      <source>
>>      <target>
>>      <frequency>60</frequency>
>>      <rest-of-ping-params ...>
>>    </ping>
>>   </rpc>
>>
>>   <rpc-reply  message-id="101">
>>     <ok/>
>>   </rpc-reply>
>>
>>   ... 60 seconds later
>>
>>   <notification>
>>     <event-class>rpc-reply</event-class>
>>     <sequence-id>42</sequence-id>
>>     <data>
>>       <rpc-reply message-id="101">
>>         ...  ping result # 1
>>       </rpc-reply>
>>     </data>
>>   </notification>
>>
>>  ... 60 seconds later
>>
>>   <notification>
>>     <event-class>rpc-reply</event-class>
>>     <sequence-id>43</sequence-id>
>>     <data>
>>       <rpc-reply message-id="101">
>>         ...  ping result # 2
>>       </rpc-reply>
>>     </data>
>>   </notification>
>>
>>
>>
>>> - METRICS is certainly out of scope although I don't see any real 
>>> problem with it. We must note however that Netconf events are 
>>> probably unsuitable for HIGH volume performance data transfer.
>>
>>
>> The problem with it is that netconf is chartered
>> for a completely different purpose.  The ipfix protocol
>> is designed much more appropriately for streaming metrics
>> data from source to sink.  They made very different design
>> choices than netconf because they are solving a different
>> problem.  Streaming metrics data encoded in XML over a session
>> over TCP seems rather inefficient to me.
>>
>>
>>> - HEART BEAT - OK
>>> - INFORMATION event is really an extension mechanism. OK.
>>
>> why not call it 'other' then?
>>
>>> - SYSLOG: We spoke a lot about transferring syslog via events, but 
>>> please could someone say who really has a requirement to do this! If 
>>> we really have the requirement Jurgen please add it to your page!
>>
>> IMO syslog is not an event classification at all
>> and does not belong in the set, unless it indicates
>> the exact content of the payload (like my rpc-reply event class.)
>> Is is syslog/RAW or syslog/COOKED or something else?
>> If I need to depend on the namespace URIs in the data anyway,
>> then what value is this classification?
>>
>> I agree with you that it doesn't make a lot of sense
>> to tunnel syslog over netconf, but from a dev-cost POV,
>> it would be easy to implement syslog/RAW over netconf.
>> It would provide no additional value whatsoever from a modeling
>> perspective, but maybe it does from a transport and
>> security perspective.
>>
>>
>>
>>> - SECURITY - mentioned in the initial list, but not described later. 
>>> As I see it security related notifications can be carried as fault or 
>>> state events, so I don't see a need for this event class.
>>>
>>
>> agreed
>>
>>> Balazs
>>
>>
>> Andy
>>
>>
>>
>>>
>>> Andy Bierman wrote:
>>>> Hi,
>>>>
>>>> This section is very under-specified.
>>>>
>>>> IMO, it is impossible for independent developers
>>>> to select classifications in an interoperable manner.
>>>>
>>>> It is really not at all clear why we need audit, data,
>>>> maintenance, metrics, information, and syslog classes at all.
>>>>
>>>> Most of these are totally redundant.
>>>>
>>>> Metrics is out of scope.
>>>>
>>>> Syslog is not a proper member of this classification set.
>>>> In XML, we use namespaces to identify content format,
>>>> such as syslog/RAW, syslog/COOKED, acme/TOASTED, etc.
>>>> The notification <data> section will be just like
>>>> the <config> or <data> elements already defined in
>>>> the protocol.
>>>>
>>>> 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: <http://ops.ietf.org/lists/netconf/>
>>>
>>>
>>> -- 
>>> to unsubscribe send a message to netconf-request@ops.ietf.org with
>>> the word 'unsubscribe' in a single line as the message text body.
>>> archive: <http://ops.ietf.org/lists/netconf/>
>>>
>>>
>>
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 18 09:03:41 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgiAH-0004R7-V9
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 09:03:41 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FgiAG-000074-Fu
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 09:03:41 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fgi53-000ICT-Nr
	for netconf-data@psg.com; Thu, 18 May 2006 12:58:17 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fgi52-000ICF-Qu
	for netconf@ops.ietf.org; Thu, 18 May 2006 12:58:16 +0000
Received: from mail.networksolutionsemail.com (ns-omr5.mgt.hosting.dc2.netsol.com [10.49.6.68])
	by ns-omrbm5.netsolmail.com (8.13.6/8.13.6) with SMTP id k4ICwF1c010655
	for <netconf@ops.ietf.org>; Thu, 18 May 2006 08:58:16 -0400
Received: (qmail 21004 invoked by uid 78); 18 May 2006 12:58:15 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.68 with SMTP; 18 May 2006 12:58:15 -0000
Message-ID: <446C6F45.3070104@andybierman.com>
Date: Thu, 18 May 2006 05:57:41 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: event classes (sec. 3.5)
References: <445B7A1C.9090803@andybierman.com> <4469E01A.9040604@ericsson.com> <446B9FAB.2050402@andybierman.com> <446C6649.4070004@ericsson.com>
In-Reply-To: <446C6649.4070004@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: bf422c85703d3d847fb014987125ac48

Balazs Lengyel wrote:
> Hello,
> In Ericsson every managed object (conceptually similar to an XML 
> element) can have both data (children) and associated actions. These are 
> commands whose primary aim is NOT to set data but to do something like 
> your ping. The possible actions are part of the data model so we only 
> need one extra operation like <execute-action with parameters>.
> 
> As netconf is missing this feature we intended to do a workaround but I 
> would be much more happy to see this in netconf itself. I just didn't 
> bring it up as yet as there were so many other topics to discuss.


Actually netconf already has this feature.
You can define your own <rpc> requests in your own namespace.
The WG debated whether or not to have an explicit <exec>
operation, but decided it was redundant.

This is also an area where snmp/cli/netconf unification
comes into play (in my research anyway) -- i.e., a netconf API
to the REMOPS-MIB in this case.


> 
> I wonder how Juniper solved this? They had Junos-script and operational 
> mode commands like ping for a long time.
> 
> Balazs

Andy

> 
> Andy Bierman wrote:
>> Balazs Lengyel wrote:
>>> ....
>>> - Ericsson needs MAINTENANCE events. See Jurgens requirement page: 
>>> "notify about delayed results of long running RPCs [BL]". I am not 
>>> totally happy with the name of the event class, but I like the idea 
>>> behind it. If the draft misses this Ericsson will have to do some 
>>> dirty workaround.
>>
>> I think this delayed <rpc-reply> should have its own event class
>> and fully defined syntax (because it's already done in the prot-spec).
>>
>> This could turn out to be an important feature.
>> IMO, a specialized RPC to provide 'ping' type of exec
>> features is a good use of session-specific config.
>> and netconf-specific session-based notifications.
>>
>> E.g.:
>>
>>  <rpc message-id="101">
>>    <ping>
>>      <source>
>>      <target>
>>      <frequency>60</frequency>
>>      <rest-of-ping-params ...>
>>    </ping>
>>   </rpc>
>>
>>   <rpc-reply  message-id="101">
>>     <ok/>
>>   </rpc-reply>
>>
>>   ... 60 seconds later
>>
>>   <notification>
>>     <event-class>rpc-reply</event-class>
>>     <sequence-id>42</sequence-id>
>>     <data>
>>       <rpc-reply message-id="101">
>>         ...  ping result # 1
>>       </rpc-reply>
>>     </data>
>>   </notification>
>>
>>  ... 60 seconds later
>>
>>   <notification>
>>     <event-class>rpc-reply</event-class>
>>     <sequence-id>43</sequence-id>
>>     <data>
>>       <rpc-reply message-id="101">
>>         ...  ping result # 2
>>       </rpc-reply>
>>     </data>
>>   </notification>
>>
>>
>>
>>> - METRICS is certainly out of scope although I don't see any real 
>>> problem with it. We must note however that Netconf events are 
>>> probably unsuitable for HIGH volume performance data transfer.
>>
>>
>> The problem with it is that netconf is chartered
>> for a completely different purpose.  The ipfix protocol
>> is designed much more appropriately for streaming metrics
>> data from source to sink.  They made very different design
>> choices than netconf because they are solving a different
>> problem.  Streaming metrics data encoded in XML over a session
>> over TCP seems rather inefficient to me.
>>
>>
>>> - HEART BEAT - OK
>>> - INFORMATION event is really an extension mechanism. OK.
>>
>> why not call it 'other' then?
>>
>>> - SYSLOG: We spoke a lot about transferring syslog via events, but 
>>> please could someone say who really has a requirement to do this! If 
>>> we really have the requirement Jurgen please add it to your page!
>>
>> IMO syslog is not an event classification at all
>> and does not belong in the set, unless it indicates
>> the exact content of the payload (like my rpc-reply event class.)
>> Is is syslog/RAW or syslog/COOKED or something else?
>> If I need to depend on the namespace URIs in the data anyway,
>> then what value is this classification?
>>
>> I agree with you that it doesn't make a lot of sense
>> to tunnel syslog over netconf, but from a dev-cost POV,
>> it would be easy to implement syslog/RAW over netconf.
>> It would provide no additional value whatsoever from a modeling
>> perspective, but maybe it does from a transport and
>> security perspective.
>>
>>
>>
>>> - SECURITY - mentioned in the initial list, but not described later. 
>>> As I see it security related notifications can be carried as fault or 
>>> state events, so I don't see a need for this event class.
>>>
>>
>> agreed
>>
>>> Balazs
>>
>>
>> Andy
>>
>>
>>
>>>
>>> Andy Bierman wrote:
>>>> Hi,
>>>>
>>>> This section is very under-specified.
>>>>
>>>> IMO, it is impossible for independent developers
>>>> to select classifications in an interoperable manner.
>>>>
>>>> It is really not at all clear why we need audit, data,
>>>> maintenance, metrics, information, and syslog classes at all.
>>>>
>>>> Most of these are totally redundant.
>>>>
>>>> Metrics is out of scope.
>>>>
>>>> Syslog is not a proper member of this classification set.
>>>> In XML, we use namespaces to identify content format,
>>>> such as syslog/RAW, syslog/COOKED, acme/TOASTED, etc.
>>>> The notification <data> section will be just like
>>>> the <config> or <data> elements already defined in
>>>> the protocol.
>>>>
>>>> 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: <http://ops.ietf.org/lists/netconf/>
>>>
>>>
>>> -- 
>>> to unsubscribe send a message to netconf-request@ops.ietf.org with
>>> the word 'unsubscribe' in a single line as the message text body.
>>> archive: <http://ops.ietf.org/lists/netconf/>
>>>
>>>
>>
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 18 09:28:12 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgiY0-00046I-2x
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 09:28:12 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fghb8-00071T-3q
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 08:27:22 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FghMQ-00023z-21
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 08:12:12 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FghIl-000ETc-Lr
	for netconf-data@psg.com; Thu, 18 May 2006 12:08:23 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FghIk-000ETO-Qz
	for netconf@ops.ietf.org; Thu, 18 May 2006 12:08:22 +0000
Received: from mail.networksolutionsemail.com (ns-omr5.mgt.hosting.dc2.netsol.com [10.49.6.68])
	by ns-omrbm5.netsolmail.com (8.13.6/8.13.6) with SMTP id k4IC8Mpn015295
	for <netconf@ops.ietf.org>; Thu, 18 May 2006 08:08:22 -0400
Received: (qmail 23824 invoked by uid 78); 18 May 2006 12:08:22 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.68 with SMTP; 18 May 2006 12:08:22 -0000
Message-ID: <446C639A.1000506@andybierman.com>
Date: Thu, 18 May 2006 05:07:54 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: The datamodel in Notification Draft
References: <713043CE8B8E1348AF3C546DBE02C1B4086CC037@zcarhxm2.corp.nortel.com> <446B4FDB.6000102@ericsson.com> <446B5BF5.5040102@andybierman.com> <446C5792.6050306@ericsson.com> <446C5FBB.70801@andybierman.com> <446C61BE.6060709@ericsson.com>
In-Reply-To: <446C61BE.6060709@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.2 (--)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da

Balazs Lengyel wrote:
>>> Andy Bierman wrote:
>>>> Balazs Lengyel wrote:
>>>>> Hello,
>>>>> Some comments to Andy's model:
>>>>> We need the concept of "Ongoing Notification Session" (subscription 
>>>>> in the draft)
>>>>> We need this as we do not want to open a new session for each 
>>>>> notification for each target. We need to store the existing 
>>>>> sessionId and reuse it.
>>>>
>>>>
>>>> IMO, there isn't any session-based notification system
>>>> that makes sense.  We should not reinvent UDP
>>>> based notification architecture with some hack to
>>>> get around the overhead of sessions.
>>>>
>>>> The notion of a session that exists even if the other
>>>> peer in the session does not exist -- is extremely broken.
>>>> Is this what you mean by "ongoing session"?
>>>
>>> NO. But if the other end does not exists (callHome) the node tries to 
>>> set up a session to it. If the peer really doesn't exist the session 
>>> setup fails the notification will not be sent. But if the peer exists 
>>> just the session between the manager and the agent is missing the 
>>> agent should be able to rebuild it.
>>
>>
>> This is significantly more complex than the traditional
>> NV-configured fire-and-forget UDP-based notification systems.
>> If any part of the "use-UDP-instead-of-TCP when the network
>> is unstable" doctrine is still true, then it is for fault
>> notifications.
> 
> Currently we have 3 transport SSH, BEEP and SOAP so UDP would be 
> something new. Do you suggest we should go for UDP or what is your 
> proposal ?


No -- you are missing my point.
I am not convinced that netconf is an appropriate protocol
to replace the functionality of syslog.  I would just
use syslog if I wanted a notification system that scales.
If I wanted a nice-to-have feature to make NMS netconf dev-work
a little easier, I would consider using netconf notifications.


> 
> For mixed notification sessions we anyway need to maintain the session.
> 
> JURGEN! Could you tell us how ISMS is solving the session based security?
> As I understand they also decided to have proper security you need to 
> maintain sessions.
> 
> Balazs
> 
> 

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 18 09:29:51 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgiY0-00046I-Rr
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 09:28:12 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FgiSt-0000nI-Ne
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 09:22:57 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FgiPQ-000JmZ-KV
	for netconf-data@psg.com; Thu, 18 May 2006 13:19:20 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [212.201.44.23] (helo=hermes.iu-bremen.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <j.schoenwaelder@iu-bremen.de>)
	id 1FgiPQ-000JmN-0P
	for netconf@ops.ietf.org; Thu, 18 May 2006 13:19:20 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 3AB5F4D3EA;
	Thu, 18 May 2006 15:19:19 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23])
 by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024)
 with ESMTP id 30265-05; Thu, 18 May 2006 15:19:17 +0200 (CEST)
Received: from boskop.local (unknown [10.222.1.3])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id 09E3755D11;
	Thu, 18 May 2006 15:19:12 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id CA60F6E16E2; Thu, 18 May 2006 15:19:09 +0200 (CEST)
Date: Thu, 18 May 2006 15:19:09 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Scalability as requirement
Message-ID: <20060518131909.GA8383@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Balazs Lengyel <balazs.lengyel@ericsson.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
References: <446C5E4E.4020803@ericsson.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <446C5E4E.4020803@ericsson.com>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126

On Thu, May 18, 2006 at 01:45:18PM +0200, Balazs Lengyel wrote:
> Jurgen,
> Could you please add scalability to your requirements page. After the 
> discussions I believe we require that the protocol should allow 30.000 to 
> 100.000 nodes to send notifications to a management station and the station 
> should be able to order the 100.000 nodes to send the notifications.

Added to the list.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 18 09:40:31 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fgijv-0000cK-G5
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 09:40:31 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fgiju-0001sr-0u
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 09:40:31 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fgift-000L9l-4H
	for netconf-data@psg.com; Thu, 18 May 2006 13:36:21 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS autolearn=no version=3.1.1
Received: from [204.127.192.84] (helo=rwcrmhc14.comcast.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <dbharrington@comcast.net>)
	id 1Fgifs-000L9V-AC
	for netconf@ops.ietf.org; Thu, 18 May 2006 13:36:20 +0000
Received: from harrington73653 (c-24-128-66-70.hsd1.nh.comcast.net[24.128.66.70])
          by comcast.net (rwcrmhc14) with SMTP
          id <20060518131213m1400kiq9je>; Thu, 18 May 2006 13:12:14 +0000
From: "David B Harrington" <dbharrington@comcast.net>
To: "'Netconf \(E-mail\)'" <netconf@ops.ietf.org>
Subject: netconf notifications review
Date: Thu, 18 May 2006 09:11:20 -0400
Message-ID: <075a01c67a7c$8ec6bb80$0400a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d

Hi Andy,

> I would appreciate it if you could read the
> latest notification draft and either fully review it
> or send comments in context of your requirements.
>=20

I will try to do a review for you, but a detailed review probably
won't be very soon.
I am editing two ISMS documents and chairing the syslog WG, and
preparing other documents and presentations before Montreal,=20
preparing a MIB template in xml2rfc format and doing reviews as
part of the security directorate. I also need to work with my team to
implement netconf protocol so we can contribute more effectively.=20
Netconf notifications definitely fall after those in my priority list.

I would appreciate it if you (and others in the netconf community)
would review the ISMS documents.=20
ISMS is dealing with issues netconf also needs to address, such as
session-based management and (VACM-independent) access control and
architectural issues; I would like to see some consistency in the
approaches to make deployment of both protocols in the same system
easier (not necessarily integration or reuse, but consistency in some
of the design decisions).

I think you'll get more from reviewing those than I expect to get from
reviewing the netconf notifications draft; I am unconvinced
notifications are needed for configuration. It doesn't much matter if
Sharon's XSD is correct or not if netconf doesn't need notifications
to perform its primary mission well.
-

I am concerned that the netconf WG is adding nice-to-have, not
must-have, features to the original scope, and Sharon keeps talking
about some unnamed applications that can run over the same channel,
and so on. I saw COPS-PR try to expand beyond its original
configuration scope, and it died as it tried to retrofit its design to
the new requirements (like message security and access control) as
well as dying for political reasons and a perpetual lock.=20

Netconf is focusing on nice-to-have features like notifications and
not=20
addressing real issues it will have to address, like data modeling and

access control, that are likely to impact the protocol design.

This makes me fear for the future of netconf. That is why I am pushing
for a discussion of what is the purpose of netconf, so we can bring it
out in the open and get consensus on the direction, and the
requirements. It is also why I am pushing for a management framework -
so we can discuss how snmp and syslog and netconf fit together in an
overall management protocol toolkit, much as ping, telnet, netstat,
cli, and snmpv1 have fit together as a management toolkit in the past.

This is the same type of discussion that is needed in a company that
produces multiple products or product lines with overlapping
functionality. We need to understand how the pieces can be used
together to form a system rather than competing with each other by
duplicating functionality.

If netconf tries to do everything, it will likely stop doing one thing
well and end up doing all things poorly.=20

The netconf community needs to decide what netconf should be designed
to do. And so far, I do not see consensus on that point.

dbh




--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 18 09:45:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgioZ-0002IX-L2
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 09:45:19 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FghbR-00071T-Cs
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 08:27:41 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FghLg-00022n-QM
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 08:11:27 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FghHd-000EON-G7
	for netconf-data@psg.com; Thu, 18 May 2006 12:07:13 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FghHb-000EO7-SP
	for netconf@ops.ietf.org; Thu, 18 May 2006 12:07:12 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E6B45C9E;
	Thu, 18 May 2006 14:07:10 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 18 May 2006 14:07:10 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 18 May 2006 14:07:10 +0200
Message-ID: <446C636E.1030600@ericsson.com>
Date: Thu, 18 May 2006 14:07:10 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: event classes (sec. 3.5)
References: <445B7A1C.9090803@andybierman.com> <4469E01A.9040604@ericsson.com> <446B9FAB.2050402@andybierman.com>
In-Reply-To: <446B9FAB.2050402@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 May 2006 12:07:10.0591 (UTC) FILETIME=[975CD8F0:01C67A73]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.6 (--)
X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d

I was extremely glad to read you mail !!!!
- By the way we have a similar multiple reply feature called "one-to-many exchange" in 
BEEP as well so the concept is not new.
- On the other hand Sharon's definition includes automatic maintenance action. Let's say 
we have a daily automatic backup and I want a notification that it succeeded. Which event 
class would you choose for this ?

Balazs


Andy Bierman wrote:
> Balazs Lengyel wrote:
>> ....
>> - Ericsson needs MAINTENANCE events. See Jurgens requirement page: 
>> "notify about delayed results of long running RPCs [BL]". I am not 
>> totally happy with the name of the event class, but I like the idea 
>> behind it. If the draft misses this Ericsson will have to do some 
>> dirty workaround.
> 
> I think this delayed <rpc-reply> should have its own event class
> and fully defined syntax (because it's already done in the prot-spec).
> 
> This could turn out to be an important feature.
> IMO, a specialized RPC to provide 'ping' type of exec
> features is a good use of session-specific config.
> and netconf-specific session-based notifications.
> 
> E.g.:
> 
>  <rpc message-id="101">
>    <ping>
>      <source>
>      <target>
>      <frequency>60</frequency>
>      <rest-of-ping-params ...>
>    </ping>
>   </rpc>
> 
>   <rpc-reply  message-id="101">
>     <ok/>
>   </rpc-reply>
> 
>   ... 60 seconds later
> 
>   <notification>
>     <event-class>rpc-reply</event-class>
>     <sequence-id>42</sequence-id>
>     <data>
>       <rpc-reply message-id="101">
>         ...  ping result # 1
>       </rpc-reply>
>     </data>
>   </notification>
> 
>  ... 60 seconds later
> 
>   <notification>
>     <event-class>rpc-reply</event-class>
>     <sequence-id>43</sequence-id>
>     <data>
>       <rpc-reply message-id="101">
>         ...  ping result # 2
>       </rpc-reply>
>     </data>
>   </notification>
> 
> 
> 
>> - METRICS is certainly out of scope although I don't see any real 
>> problem with it. We must note however that Netconf events are probably 
>> unsuitable for HIGH volume performance data transfer.
> 
> 
> The problem with it is that netconf is chartered
> for a completely different purpose.  The ipfix protocol
> is designed much more appropriately for streaming metrics
> data from source to sink.  They made very different design
> choices than netconf because they are solving a different
> problem.  Streaming metrics data encoded in XML over a session
> over TCP seems rather inefficient to me.
> 
> 
>> - HEART BEAT - OK
>> - INFORMATION event is really an extension mechanism. OK.
> 
> why not call it 'other' then?
> 
>> - SYSLOG: We spoke a lot about transferring syslog via events, but 
>> please could someone say who really has a requirement to do this! If 
>> we really have the requirement Jurgen please add it to your page!
> 
> IMO syslog is not an event classification at all
> and does not belong in the set, unless it indicates
> the exact content of the payload (like my rpc-reply event class.)
> Is is syslog/RAW or syslog/COOKED or something else?
> If I need to depend on the namespace URIs in the data anyway,
> then what value is this classification?
> 
> I agree with you that it doesn't make a lot of sense
> to tunnel syslog over netconf, but from a dev-cost POV,
> it would be easy to implement syslog/RAW over netconf.
> It would provide no additional value whatsoever from a modeling
> perspective, but maybe it does from a transport and
> security perspective.
> 
> 
> 
>> - SECURITY - mentioned in the initial list, but not described later. 
>> As I see it security related notifications can be carried as fault or 
>> state events, so I don't see a need for this event class.
>>
> 
> agreed
> 
>> Balazs
> 
> 
> Andy
> 
> 
> 
>>
>> Andy Bierman wrote:
>>> Hi,
>>>
>>> This section is very under-specified.
>>>
>>> IMO, it is impossible for independent developers
>>> to select classifications in an interoperable manner.
>>>
>>> It is really not at all clear why we need audit, data,
>>> maintenance, metrics, information, and syslog classes at all.
>>>
>>> Most of these are totally redundant.
>>>
>>> Metrics is out of scope.
>>>
>>> Syslog is not a proper member of this classification set.
>>> In XML, we use namespaces to identify content format,
>>> such as syslog/RAW, syslog/COOKED, acme/TOASTED, etc.
>>> The notification <data> section will be just like
>>> the <config> or <data> elements already defined in
>>> the protocol.
>>>
>>> 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: <http://ops.ietf.org/lists/netconf/>
>>
>>
>> -- 
>> to unsubscribe send a message to netconf-request@ops.ietf.org with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
>>
>>
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 18 09:57:06 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fgizy-0005oq-IG
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 09:57:06 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fgizy-0002hw-Gt
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 09:57:06 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1Fgiwi-0003C1-Ot
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 09:53:46 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FgisL-000MAR-ED
	for netconf-data@psg.com; Thu, 18 May 2006 13:49:13 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FgisK-000MAF-Qt
	for netconf@ops.ietf.org; Thu, 18 May 2006 13:49:12 +0000
Received: from mail.networksolutionsemail.com (ns-omr3.mgt.hosting.dc2.netsol.com [10.49.6.66])
	by ns-omrbm3.netsolmail.com (8.13.6/8.13.6) with SMTP id k4IDnCWs009077
	for <netconf@ops.ietf.org>; Thu, 18 May 2006 09:49:12 -0400
Received: (qmail 16796 invoked by uid 78); 18 May 2006 13:49:11 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.66 with SMTP; 18 May 2006 13:49:11 -0000
Message-ID: <446C7B30.5050101@andybierman.com>
Date: Thu, 18 May 2006 06:48:32 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Scalability as requirement
References: <446C5E4E.4020803@ericsson.com> <20060518131909.GA8383@boskop.local>
In-Reply-To: <20060518131909.GA8383@boskop.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.3 (--)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb

Juergen Schoenwaelder wrote:
> On Thu, May 18, 2006 at 01:45:18PM +0200, Balazs Lengyel wrote:
>> Jurgen,
>> Could you please add scalability to your requirements page. After the 
>> discussions I believe we require that the protocol should allow 30.000 to 
>> 100.000 nodes to send notifications to a management station and the station 
>> should be able to order the 100.000 nodes to send the notifications.
> 

This is a really poorly worded requirement.
A million nodes could send notifications.
The protocol does not actually constrain the number
of nodes that can participate in netconf sessions.
Nor would it.

Operational scalability is hard to quantify, and it
of course depends on your acceptable failure response time
and security requirements.  I don't want to specify maximum
event-to-delivery latency times in the netconf standard.
I don't know how to write this requirement in a meaningful
and acceptable way.


IMO, Callhome could sufficiently address the scalability problem
wrt/ manager-subscribe based delays, if it was fully specified.
The relative overhead of establishing a netconf session to send
secure notifications is debatable I guess, about the same any
way you do it (if you decide up front you want to use sessions).


> Added to the list.
> 
> /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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 18 10:21:29 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgjNZ-0006MS-Qx
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 10:21:29 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FgjNX-0004Mi-C2
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 10:21:29 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FgjEs-000O7T-2o
	for netconf-data@psg.com; Thu, 18 May 2006 14:12:30 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FgjEr-000O7E-7k
	for netconf@ops.ietf.org; Thu, 18 May 2006 14:12:29 +0000
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.hosting.dc2.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k4IECNKQ019058
	for <netconf@ops.ietf.org>; Thu, 18 May 2006 10:12:28 -0400
Received: (qmail 3923 invoked by uid 78); 18 May 2006 14:12:23 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 18 May 2006 14:12:23 -0000
Message-ID: <446C8096.5010004@andybierman.com>
Date: Thu, 18 May 2006 07:11:34 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: David B Harrington <dbharrington@comcast.net>
CC: "'Netconf (E-mail)'" <netconf@ops.ietf.org>
Subject: Re: netconf notifications review
References: <075a01c67a7c$8ec6bb80$0400a8c0@china.huawei.com>
In-Reply-To: <075a01c67a7c$8ec6bb80$0400a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8

David B Harrington wrote:
> Hi Andy,
> 
>> I would appreciate it if you could read the
>> latest notification draft and either fully review it
>> or send comments in context of your requirements.
>>
> 
> I will try to do a review for you, but a detailed review probably
> won't be very soon.
> I am editing two ISMS documents and chairing the syslog WG, and
> preparing other documents and presentations before Montreal, 
> preparing a MIB template in xml2rfc format and doing reviews as
> part of the security directorate. I also need to work with my team to
> implement netconf protocol so we can contribute more effectively. 
> Netconf notifications definitely fall after those in my priority list.
> 

Netconf implementation is actually first on my priority list.
I will volunteer to review 1 or both ISMS documents if you review
the notifications document.

(First RAQMON, now this -- I don't want to learn about security! ;-)


> I would appreciate it if you (and others in the netconf community)
> would review the ISMS documents. 
> ISMS is dealing with issues netconf also needs to address, such as
> session-based management and (VACM-independent) access control and
> architectural issues; I would like to see some consistency in the
> approaches to make deployment of both protocols in the same system
> easier (not necessarily integration or reuse, but consistency in some
> of the design decisions).
> 
> I think you'll get more from reviewing those than I expect to get from
> reviewing the netconf notifications draft; I am unconvinced
> notifications are needed for configuration. It doesn't much matter if
> Sharon's XSD is correct or not if netconf doesn't need notifications
> to perform its primary mission well.
> -
> 
> I am concerned that the netconf WG is adding nice-to-have, not
> must-have, features to the original scope, and Sharon keeps talking
> about some unnamed applications that can run over the same channel,
> and so on. I saw COPS-PR try to expand beyond its original
> configuration scope, and it died as it tried to retrofit its design to
> the new requirements (like message security and access control) as
> well as dying for political reasons and a perpetual lock. 
> 
> Netconf is focusing on nice-to-have features like notifications and
> not 
> addressing real issues it will have to address, like data modeling and
> 
> access control, that are likely to impact the protocol design.


I can't speak for others, but I am trying to address these problems
(and more) with running code, not I-Ds.  Documentation of this research
when it is done is a possibility, but not a priority.


> 
> This makes me fear for the future of netconf. That is why I am pushing
> for a discussion of what is the purpose of netconf, so we can bring it
> out in the open and get consensus on the direction, and the
> requirements. It is also why I am pushing for a management framework -
> so we can discuss how snmp and syslog and netconf fit together in an
> overall management protocol toolkit, much as ping, telnet, netstat,
> cli, and snmpv1 have fit together as a management toolkit in the past.
> 
> This is the same type of discussion that is needed in a company that
> produces multiple products or product lines with overlapping
> functionality. We need to understand how the pieces can be used
> together to form a system rather than competing with each other by
> duplicating functionality.


In a company, one of your first steps might be to have some people explore
the solution space and even prototype the most promising solution approach.
After that, you can discuss the problem with some understanding
of the probability and cost of solving it.

I don't think the vendors and operators have enough experience
with netconf to really understand all the integration requirements.



> 
> If netconf tries to do everything, it will likely stop doing one thing
> well and end up doing all things poorly. 


It hasn't actually started to do 1 thing well yet.


> 
> The netconf community needs to decide what netconf should be designed
> to do. And so far, I do not see consensus on that point.

I don't either, be we will keep looking for consensus anyway.


> 
> dbh


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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 18 10:30:04 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgjVs-0000Me-JW
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 10:30:04 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FgjVq-0005Ir-8b
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 10:30:04 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FgjPp-000OyN-46
	for netconf-data@psg.com; Thu, 18 May 2006 14:23:49 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [192.11.226.163] (helo=hoemail2.lucent.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <bwijnen@lucent.com>)
	id 1FgjPJ-000OwE-Me
	for netconf@ops.ietf.org; Thu, 18 May 2006 14:23:17 +0000
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k4IENBvQ008364;
	Thu, 18 May 2006 09:23:12 -0500 (CDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <JHK4D7A9>; Thu, 18 May 2006 16:23:10 +0200
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550A13AE1E@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: j.schoenwaelder@iu-bremen.de,
        Balazs Lengyel
	 <balazs.lengyel@ericsson.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: RE: Scalability as requirement
Date: Thu, 18 May 2006 16:23:09 +0200
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002

All nice that it has been added to the list.

But (as far as I understand), the list is currently just a 
collection of things that various people have posted to this list.

In no way does it (yet) represent any consensus of this WG. 
Is there any plan to try and see if we as a WG 
can in fact get any consensus on what the need/requirements are?

Bert

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Juergen Schoenwaelder
> Sent: Thursday, May 18, 2006 15:19
> To: Balazs Lengyel
> Cc: Netconf (E-mail)
> Subject: Re: Scalability as requirement
> 
> 
> On Thu, May 18, 2006 at 01:45:18PM +0200, Balazs Lengyel wrote:
> > Jurgen,
> > Could you please add scalability to your requirements page. 
> After the 
> > discussions I believe we require that the protocol should 
> allow 30.000 to 
> > 100.000 nodes to send notifications to a management station 
> and the station 
> > should be able to order the 100.000 nodes to send the notifications.
> 
> Added to the list.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    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: <http://ops.ietf.org/lists/netconf/>
> 

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 18 11:29:40 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgkRY-0007eb-OT
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 11:29:40 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FgkRX-0000Bk-Cm
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 11:29:40 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FgkGQ-0003GR-C2
	for netconf-data@psg.com; Thu, 18 May 2006 15:18:10 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FgkGP-0003GF-7j
	for netconf@ops.ietf.org; Thu, 18 May 2006 15:18:09 +0000
Received: from mail.networksolutionsemail.com (ns-omr6.mgt.hosting.dc2.netsol.com [10.49.6.69])
	by ns-omrbm6.netsolmail.com (8.13.6/8.13.6) with SMTP id k4IFI8WJ016112
	for <netconf@ops.ietf.org>; Thu, 18 May 2006 11:18:08 -0400
Received: (qmail 4497 invoked by uid 78); 18 May 2006 15:18:07 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.69 with SMTP; 18 May 2006 15:18:07 -0000
Message-ID: <446C8FF7.2060201@andybierman.com>
Date: Thu, 18 May 2006 08:17:11 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
CC: j.schoenwaelder@iu-bremen.de, Balazs Lengyel <balazs.lengyel@ericsson.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Scalability as requirement
References: <7D5D48D2CAA3D84C813F5B154F43B1550A13AE1E@nl0006exch001u.nl.lucent.com>
In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550A13AE1E@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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81

Wijnen, Bert (Bert) wrote:
> All nice that it has been added to the list.
> 
> But (as far as I understand), the list is currently just a 
> collection of things that various people have posted to this list.
> 
> In no way does it (yet) represent any consensus of this WG. 
> Is there any plan to try and see if we as a WG 
> can in fact get any consensus on what the need/requirements are?

I was trying to get the requirements captured in the document.
That has not happened yet.  There have been few people willing
to review the notifications draft.  Very few people have RSVPed
for the interim meeting in Montreal as well.

The hope is that a 2 day interim meeting will allow us to
prioritize the requirements list, and as Dave put it,
understand netconf's role in a workable NM architecture
that includes many protocols and many usage scenarios.

We should try to do this on the mailing list first I guess.

> 
> Bert

Andy

> 
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
>> Behalf Of Juergen Schoenwaelder
>> Sent: Thursday, May 18, 2006 15:19
>> To: Balazs Lengyel
>> Cc: Netconf (E-mail)
>> Subject: Re: Scalability as requirement
>>
>>
>> On Thu, May 18, 2006 at 01:45:18PM +0200, Balazs Lengyel wrote:
>>> Jurgen,
>>> Could you please add scalability to your requirements page. 
>> After the 
>>> discussions I believe we require that the protocol should 
>> allow 30.000 to 
>>> 100.000 nodes to send notifications to a management station 
>> and the station 
>>> should be able to order the 100.000 nodes to send the notifications.
>> Added to the list.
>>
>> /js
>>
>> -- 
>> Juergen Schoenwaelder		    International University Bremen
>> <http://www.eecs.iu-bremen.de/>	    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: <http://ops.ietf.org/lists/netconf/>
>>
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 18 12:33:00 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FglQq-0005Ez-5N
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 12:33:00 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FglQo-0004Xp-M1
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 12:33:00 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FglLB-0007TR-04
	for netconf-data@psg.com; Thu, 18 May 2006 16:27:09 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1
Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <htrevino@cisco.com>)
	id 1FglLA-0007Su-6Q
	for netconf@ops.ietf.org; Thu, 18 May 2006 16:27:08 +0000
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
  by sj-iport-3.cisco.com with ESMTP; 18 May 2006 09:27:08 -0700
X-IronPort-AV: i="4.05,142,1146466800"; 
   d="scan'208"; a="427772500:sNHT33406132"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4IGR7On024076;
	Thu, 18 May 2006 09:27:07 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4IGR6BD019176;
	Thu, 18 May 2006 09:27:07 -0700 (PDT)
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);
	 Thu, 18 May 2006 09:27:03 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: The datamodel in Notification Draft
Date: Thu, 18 May 2006 09:27:02 -0700
Message-ID: <6E21698722408147BEA594E073E2B0AB01DF5A96@xmb-sjc-223.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: The datamodel in Notification Draft
Thread-Index: AcZ6c8xQwYWQs2GAQ0C2K31Cj5V+kgAIyY3w
From: "Hector Trevino \(htrevino\)" <htrevino@cisco.com>
To: "Andy Bierman" <ietf@andybierman.com>,
        "Balazs Lengyel" <balazs.lengyel@ericsson.com>
Cc: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 18 May 2006 16:27:03.0327 (UTC) FILETIME=[E55B8AF0:01C67A97]
DKIM-Signature: a=rsa-sha1; q=dns; l=3706; t=1147969627; x=1148833627;
	c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=htrevino@cisco.com; z=From:=22Hector=20Trevino=20\(htrevino\)=22=20<htrevino@cisco.com>
	|Subject:RE=3A=20The=20datamodel=20in=20Notification=20Draft;
	X=v=3Dcisco.com=3B=20h=3DgJ5VOFNfkcy8hfexFgR+xzMgc1U=3D; b=M5yPC52YgG7wi7S6purM9Swei2HAYxe9OKjtyCjWRGLyzaq/cL7WIkN6Hjqh++e7TblogJmf
	yz7NMZQXj0Dr6sQpYZkkml3u0zvU+6UhJAgLTtmPu4GRlxgoXZgWdpAc;
Authentication-Results: sj-dkim-3.cisco.com; header.From=htrevino@cisco.com; dkim=pass (
	sig from cisco.com verified; ); 
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f

=20
-- copied from below --

> No -- you are missing my point.
> I am not convinced that netconf is an appropriate protocol to=20
> replace the functionality of syslog.  I would just use syslog=20
> if I wanted a notification system that scales.
> If I wanted a nice-to-have feature to make NMS netconf=20
> dev-work a little easier, I would consider using netconf=20
> notifications.

So, you're saying that if using a connection oriented protocol, things
will not scale. Thus continue to use syslog/UDP.=20
The syslog WG has RFC3195, draft on syslog/TLS, and there had been some
discussions on syslog/SSH. As Balazs says in one of his responses there
is also the ISMS work. I don't understand how this is a problem for
NETCONF and not for others.=20



> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Thursday, May 18, 2006 6:08 AM
> To: Balazs Lengyel
> Cc: Netconf (E-mail)
> Subject: Re: The datamodel in Notification Draft
>=20
> Balazs Lengyel wrote:
> >>> Andy Bierman wrote:
> >>>> Balazs Lengyel wrote:
> >>>>> Hello,
> >>>>> Some comments to Andy's model:
> >>>>> We need the concept of "Ongoing Notification Session"=20
> >>>>> (subscription in the draft) We need this as we do not=20
> want to open=20
> >>>>> a new session for each notification for each target. We need to=20
> >>>>> store the existing sessionId and reuse it.
> >>>>
> >>>>
> >>>> IMO, there isn't any session-based notification system=20
> that makes=20
> >>>> sense.  We should not reinvent UDP based notification=20
> architecture=20
> >>>> with some hack to get around the overhead of sessions.
> >>>>
> >>>> The notion of a session that exists even if the other=20
> peer in the=20
> >>>> session does not exist -- is extremely broken.
> >>>> Is this what you mean by "ongoing session"?
> >>>
> >>> NO. But if the other end does not exists (callHome) the=20
> node tries=20
> >>> to set up a session to it. If the peer really doesn't exist the=20
> >>> session setup fails the notification will not be sent. But if the=20
> >>> peer exists just the session between the manager and the agent is=20
> >>> missing the agent should be able to rebuild it.
> >>
> >>
> >> This is significantly more complex than the traditional=20
> NV-configured=20
> >> fire-and-forget UDP-based notification systems.
> >> If any part of the "use-UDP-instead-of-TCP when the network is=20
> >> unstable" doctrine is still true, then it is for fault=20
> notifications.
> >=20
> > Currently we have 3 transport SSH, BEEP and SOAP so UDP would be=20
> > something new. Do you suggest we should go for UDP or what is your=20
> > proposal ?
>=20
>=20
> No -- you are missing my point.
> I am not convinced that netconf is an appropriate protocol to=20
> replace the functionality of syslog.  I would just use syslog=20
> if I wanted a notification system that scales.
> If I wanted a nice-to-have feature to make NMS netconf=20
> dev-work a little easier, I would consider using netconf=20
> notifications.
>=20
>=20
> >=20
> > For mixed notification sessions we anyway need to maintain=20
> the session.
> >=20
> > JURGEN! Could you tell us how ISMS is solving the session=20
> based security?
> > As I understand they also decided to have proper security=20
> you need to=20
> > maintain sessions.
> >=20
> > Balazs
> >=20
> >=20
>=20
> Andy
>=20
>=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: <http://ops.ietf.org/lists/netconf/>
>=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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 18 12:54:53 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fglm1-0007dw-39
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 12:54:53 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fglm0-0005fW-LT
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 12:54:53 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FgliU-00099d-OB
	for netconf-data@psg.com; Thu, 18 May 2006 16:51:14 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FgliS-00099B-Lt
	for netconf@ops.ietf.org; Thu, 18 May 2006 16:51:13 +0000
Received: from mail.networksolutionsemail.com (ns-omr3.mgt.hosting.dc2.netsol.com [10.49.6.66])
	by ns-omrbm3.netsolmail.com (8.13.6/8.13.6) with SMTP id k4IGpB5u007285
	for <netconf@ops.ietf.org>; Thu, 18 May 2006 12:51:11 -0400
Received: (qmail 19327 invoked by uid 78); 18 May 2006 16:51:10 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.66 with SMTP; 18 May 2006 16:51:10 -0000
Message-ID: <446CA5BC.8070006@andybierman.com>
Date: Thu, 18 May 2006 09:50:04 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Hector Trevino (htrevino)" <htrevino@cisco.com>
CC: Balazs Lengyel <balazs.lengyel@ericsson.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: The datamodel in Notification Draft
References: <6E21698722408147BEA594E073E2B0AB01DF5A96@xmb-sjc-223.amer.cisco.com>
In-Reply-To: <6E21698722408147BEA594E073E2B0AB01DF5A96@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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3

Hector Trevino (htrevino) wrote:
>  
> -- copied from below --
> 
>> No -- you are missing my point.
>> I am not convinced that netconf is an appropriate protocol to 
>> replace the functionality of syslog.  I would just use syslog 
>> if I wanted a notification system that scales.
>> If I wanted a nice-to-have feature to make NMS netconf 
>> dev-work a little easier, I would consider using netconf 
>> notifications.
> 
> So, you're saying that if using a connection oriented protocol, things
> will not scale. Thus continue to use syslog/UDP. 
> The syslog WG has RFC3195, draft on syslog/TLS, and there had been some
> discussions on syslog/SSH. As Balazs says in one of his responses there
> is also the ISMS work. I don't understand how this is a problem for
> NETCONF and not for others. 


Netconf has a <hello> exchange. So does beep.
Callhome is under-specified and not actually
coupled to notifications anyway.

If you wanted to secure the notification stream,
and you are starting with syslog and/or snmp notifications,
then it is not a foregone conclusion that you would
end up with verbose XML encoding and the netconf subscription
approach in the current draft.  It may make more sense to
simply secure the existing protocol, whether that is
syslog/TLS, syslog/SSH, or snmp/ISMS.


Andy



> 
> 
> 
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org 
>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
>> Sent: Thursday, May 18, 2006 6:08 AM
>> To: Balazs Lengyel
>> Cc: Netconf (E-mail)
>> Subject: Re: The datamodel in Notification Draft
>>
>> Balazs Lengyel wrote:
>>>>> Andy Bierman wrote:
>>>>>> Balazs Lengyel wrote:
>>>>>>> Hello,
>>>>>>> Some comments to Andy's model:
>>>>>>> We need the concept of "Ongoing Notification Session" 
>>>>>>> (subscription in the draft) We need this as we do not 
>> want to open 
>>>>>>> a new session for each notification for each target. We need to 
>>>>>>> store the existing sessionId and reuse it.
>>>>>>
>>>>>> IMO, there isn't any session-based notification system 
>> that makes 
>>>>>> sense.  We should not reinvent UDP based notification 
>> architecture 
>>>>>> with some hack to get around the overhead of sessions.
>>>>>>
>>>>>> The notion of a session that exists even if the other 
>> peer in the 
>>>>>> session does not exist -- is extremely broken.
>>>>>> Is this what you mean by "ongoing session"?
>>>>> NO. But if the other end does not exists (callHome) the 
>> node tries 
>>>>> to set up a session to it. If the peer really doesn't exist the 
>>>>> session setup fails the notification will not be sent. But if the 
>>>>> peer exists just the session between the manager and the agent is 
>>>>> missing the agent should be able to rebuild it.
>>>>
>>>> This is significantly more complex than the traditional 
>> NV-configured 
>>>> fire-and-forget UDP-based notification systems.
>>>> If any part of the "use-UDP-instead-of-TCP when the network is 
>>>> unstable" doctrine is still true, then it is for fault 
>> notifications.
>>> Currently we have 3 transport SSH, BEEP and SOAP so UDP would be 
>>> something new. Do you suggest we should go for UDP or what is your 
>>> proposal ?
>>
>> No -- you are missing my point.
>> I am not convinced that netconf is an appropriate protocol to 
>> replace the functionality of syslog.  I would just use syslog 
>> if I wanted a notification system that scales.
>> If I wanted a nice-to-have feature to make NMS netconf 
>> dev-work a little easier, I would consider using netconf 
>> notifications.
>>
>>
>>> For mixed notification sessions we anyway need to maintain 
>> the session.
>>> JURGEN! Could you tell us how ISMS is solving the session 
>> based security?
>>> As I understand they also decided to have proper security 
>> you need to 
>>> maintain sessions.
>>>
>>> Balazs
>>>
>>>
>> 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: <http://ops.ietf.org/lists/netconf/>
>>
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 18 21:25:41 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgtkL-0006OD-N7
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 21:25:41 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FgtkH-0004zC-2S
	for netconf-archive@lists.ietf.org; Thu, 18 May 2006 21:25:41 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fgte0-000AEn-I7
	for netconf-data@psg.com; Fri, 19 May 2006 01:19:08 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fgtdz-000AEa-4D
	for netconf@ops.ietf.org; Fri, 19 May 2006 01:19:07 +0000
Received: from mail.networksolutionsemail.com ([10.49.6.66])
	by ns-omrbm3.netsolmail.com (8.13.6/8.13.6) with SMTP id k4J1J69a030856
	for <netconf@ops.ietf.org>; Thu, 18 May 2006 21:19:06 -0400
Received: (qmail 16720 invoked by uid 78); 19 May 2006 01:18:48 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.66 with SMTP; 19 May 2006 01:18:48 -0000
Message-ID: <446D1C76.6090603@andybierman.com>
Date: Thu, 18 May 2006 18:16:38 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: Martin Bjorklund <mbj@tail-f.com>, netconf@ops.ietf.org
Subject: Re: nested operation attribute interoperability
References: <446A226F.4000301@andybierman.com>	<20060516.213135.106602188.mbj@tail-f.com>	<446A4926.2050704@andybierman.com> <20060517.105554.103206073.mbj@tail-f.com> <446B8CBF.5070805@andybierman.com>
In-Reply-To: <446B8CBF.5070805@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0

 >...
> 
> 1) only 'create' and 'delete' have any kind of existence tests.
>    Merge and replace can always work and never generate an error because
>    of data present or missing in the target configuration.
> 

I'm wrong again. :-(
There is another undocumented existence test. (!)
If the default-operation is 'none' for any of the
start nodes in the <config> data, and those corresponding
nodes do not exist in the target, then a data-missing
error should be generated.


[This issue is more relevant for nested dynamic tables,
  but this simple example will suffice]

   <default-operation>none</default-operation>
   <config>
     <users>
       <user operation="create">
          ... rest of entry
       </user>
     </users>
   </config>


If the <users> container does not exist in the agent yet,
then the agent is not supposed to create it, according to this PDU.
The 'none' start state was added as a feature because
the create or delete attributes sometimes must be located
in a child node and not apply to the parent.  This is needed
for access control as well as accurate operation attribute
existence tests.

Now I have to start an errata list :-(

1) data-exists error is for delete only, not replace and delete

2) data-missing error is for create and none, not just create

Note that these errors return no parameters.  I am adding
proprietary elements to identify what is or isn't missing.
Since multiple errors can occur in different sub-trees,
the rpc-error is mostly worthless without them.  This
is not the same as access-denied.  That gets checked before
any other processing of course, and suppresses any more
error messages for the restricted data.




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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 19 05:25:27 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fh1Ed-0002EH-9W
	for netconf-archive@lists.ietf.org; Fri, 19 May 2006 05:25:27 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fh1Ec-0007AI-SH
	for netconf-archive@lists.ietf.org; Fri, 19 May 2006 05:25:27 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fh18O-0007Cv-0U
	for netconf-data@psg.com; Fri, 19 May 2006 09:19:00 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1Fh18M-0007Cj-LA
	for netconf@ops.ietf.org; Fri, 19 May 2006 09:18:58 +0000
Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id 720ED40;
	Fri, 19 May 2006 11:18:57 +0200 (CEST)
Date: Fri, 19 May 2006 11:18:46 +0200 (CEST)
Message-Id: <20060519.111846.35670501.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: netconf@ops.ietf.org
Subject: Re: nested operation attribute interoperability
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <446D1C76.6090603@andybierman.com>
References: <20060517.105554.103206073.mbj@tail-f.com>
	<446B8CBF.5070805@andybierman.com>
	<446D1C76.6090603@andybierman.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab

Andy Bierman <ietf@andybierman.com> wrote:
>  >...
> > 
> > 1) only 'create' and 'delete' have any kind of existence tests.
> >    Merge and replace can always work and never generate an error because
> >    of data present or missing in the target configuration.
> > 
> 
> I'm wrong again. :-(
> There is another undocumented existence test. (!)
> If the default-operation is 'none' for any of the
> start nodes in the <config> data, and those corresponding
> nodes do not exist in the target, then a data-missing
> error should be generated.

But this is documented already in section 7.2 in the text about 'none':

         none: The target datastore is unaffected by the configuration
            in the <config> parameter, unless and until the incoming
            configuration data uses the "operation" attribute to request
            a different operation.  If the configuration in the <config>
            parameter contains data for which there is not a
            corresponding level in the target datastore, an <rpc-error>
            is returned with an <error-tag> value of data-missing.


> Now I have to start an errata list :-(
> 
> 1) data-exists error is for delete only, not replace and delete
>
> 2) data-missing error is for create and none, not just create

I think you mean

  1) data-missing error is for delete and none, not delete and replace.

(data-exists is for create only, which is what the draft says).



> Note that these errors return no parameters.  I am adding
> proprietary elements to identify what is or isn't missing.

You can always use the standard error-path, even if there's no
error-info, right?  That's what I do, and I also send an error-info
with a bad-element, although it's not required by the description in
the appendix.   (Of course this depends on how you interpret
"Error-info:  none" - does it mean "you MUST NOT send an error-info"
or "you don't have to send an error-info")


/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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 19 10:27:56 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fh5xM-0004hB-MS
	for netconf-archive@lists.ietf.org; Fri, 19 May 2006 10:27:56 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fh5xL-00030X-2G
	for netconf-archive@lists.ietf.org; Fri, 19 May 2006 10:27:56 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fh5oy-000OQq-3R
	for netconf-data@psg.com; Fri, 19 May 2006 14:19:16 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1Fh5ow-000OPs-H8
	for netconf@ops.ietf.org; Fri, 19 May 2006 14:19:14 +0000
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A80E7E0D
	for <netconf@ops.ietf.org>; Fri, 19 May 2006 16:19:13 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 19 May 2006 16:19:13 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 19 May 2006 16:19:13 +0200
Message-ID: <446DD3E0.4050804@ericsson.com>
Date: Fri, 19 May 2006 16:19:12 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Event type
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 May 2006 14:19:13.0145 (UTC) FILETIME=[33FC6690:01C67B4F]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199

Hello,
In SNMP every trap/notification has a Object Identifier which can be used as a detailed 
event type. As far as I know this is quite often used as a branching condition in manager 
programs. I feel we are missing this in the notification draft. As I see this bit of 
information quite important, I would make it a mandatory part of every notification.
I propose a short textual identifier for the event type.
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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 19 14:01:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fh9Hr-0005cb-2l
	for netconf-archive@lists.ietf.org; Fri, 19 May 2006 14:01:19 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fh9Hp-0000qv-OR
	for netconf-archive@lists.ietf.org; Fri, 19 May 2006 14:01:19 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fh9Dc-000FEW-U1
	for netconf-data@psg.com; Fri, 19 May 2006 17:56:56 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fh9Db-000FEJ-Hz
	for netconf@ops.ietf.org; Fri, 19 May 2006 17:56:56 +0000
Received: from mail.networksolutionsemail.com ([10.49.6.68])
	by ns-omrbm5.netsolmail.com (8.13.6/8.13.6) with SMTP id k4JHurLa007249
	for <netconf@ops.ietf.org>; Fri, 19 May 2006 13:56:54 -0400
Received: (qmail 15793 invoked by uid 78); 19 May 2006 17:56:36 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.68 with SMTP; 19 May 2006 17:56:36 -0000
Message-ID: <446E06CE.4000709@andybierman.com>
Date: Fri, 19 May 2006 10:56:30 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Event type
References: <446DD3E0.4050804@ericsson.com>
In-Reply-To: <446DD3E0.4050804@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464

Balazs Lengyel wrote:
> Hello,
> In SNMP every trap/notification has a Object Identifier which can be 
> used as a detailed event type. As far as I know this is quite often used 
> as a branching condition in manager programs. I feel we are missing this 
> in the notification draft. As I see this bit of information quite 
> important, I would make it a mandatory part of every notification.
> I propose a short textual identifier for the event type.


I agree.

I think a QName is used for this purpose.
We need <element name="notification-id" type="xs:QName"/>
in the <notification> element.

The owner of the namespace must manage notification
name uniqueness, and notifications cannot be nested
like data types (makes no sense).  This is the same as SNMP.



> Balazs


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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 19 14:54:13 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FhA73-0007gl-Hc
	for netconf-archive@lists.ietf.org; Fri, 19 May 2006 14:54:13 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FhA71-0004Yw-2y
	for netconf-archive@lists.ietf.org; Fri, 19 May 2006 14:54:13 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FhA2Y-000J8s-Jb
	for netconf-data@psg.com; Fri, 19 May 2006 18:49:34 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FhA2X-000J8g-K7
	for netconf@ops.ietf.org; Fri, 19 May 2006 18:49:33 +0000
Received: from mail.networksolutionsemail.com ([10.49.6.66])
	by ns-omrbm3.netsolmail.com (8.13.6/8.13.6) with SMTP id k4JInVZd010576
	for <netconf@ops.ietf.org>; Fri, 19 May 2006 14:49:32 -0400
Received: (qmail 15825 invoked by uid 78); 19 May 2006 18:49:07 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.66 with SMTP; 19 May 2006 18:49:07 -0000
Message-ID: <446E131D.7080905@andybierman.com>
Date: Fri, 19 May 2006 11:49:01 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>,
        Netconf Data Model Discussion <netconfmodel@lists.nortel.com>
Subject: max-access: access control model discussion
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86

Hi,

This discussion is somewhat out of charter scope, but since access control
for notifications and data models keeps coming up, I think we should
discuss the basics.

IMO, the max-access mechanism in the draft is too complicated,
and it doesn't account for all operation attribute and
SMI MAX-ACCESS enumerations.  I also don't understand
the preference for making the XML as complicated as possible.
I prefer simple as possible, and reusing as much SMI as
possible (without breaking netconf ;-)

Here is a snippet from the draft as an example:

 <xs:appinfo>
   <nm:minAccess><read/></nm:minAccess>
   <nm:maxAccess><read/> <write/> <create/> <delete/></nm:maxAccess>
 </xs:appinfo>

===============================================================================
Here is something to throw darts at:

I have created a hierarchical max-access enumeration,
similar to the one in SMIv2, except it adds a few
enumerations for well-known 'mid-states' which can only
be defined in DESCRIPTION clauses.


The hierarchy is:

notify-only: object can appear in a /notification/data element 
       (SMI: notify-only)

read-only: notify + object can be retrieved in any type of
       read operation  (SMI: read-only)

write-only: object can be written only if it already exists.
       No read access at all -- agent created objects for passwords, etc.
       (SMI: write-only)

create-only: object can be created and deleted, but not edited or read.
        For passwords, etc. in dynamic objects.
        (SMI: read-create + DESCRIPTION says no read or edit if 
rowStatus=active)

read-write: notify + read + object can be edited if it already exists
        (SMI: read-write)

read-create: notify + read + object can be created and deleted, but not 
edited.
        (SMI: read-create + DESCRIPTION says no edit if rowStatus=active)
        (I know this name is confusing...)

read-create-edit: notify + read + create/delete + edit
        (SMI: read-create) (alias 'all' also accepted)
  

Mapping to the Operation Attribute
----------------------------------

Key:  name : allowed max-access values (to permit the operation)


none : any value

merge: if object currently exists:
         write-only, read-write, all
       otherwise:
         create-only, read-create, all

replace: create-only, read-create, all

create:  create-only, read-create, all

delete: same as create


I've implemented this, and the code really is as easy
as the little table above suggests. This algorithm
treats a replace as a delete+create, so it doesn't
work for static (write-only or read-write) objects.
This keeps the code simpler, but is more restrictive.
Maybe too restrictive, I don't know yet.



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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 19 17:48:53 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FhCq5-00068Y-4r
	for netconf-archive@lists.ietf.org; Fri, 19 May 2006 17:48:53 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FhCq2-0000lJ-QF
	for netconf-archive@lists.ietf.org; Fri, 19 May 2006 17:48:53 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FhCli-00032p-4J
	for netconf-data@psg.com; Fri, 19 May 2006 21:44:22 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.51] (helo=ns-omrbm1.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FhClh-00032e-2m
	for netconf@ops.ietf.org; Fri, 19 May 2006 21:44:21 +0000
Received: from mail.networksolutionsemail.com ([10.49.6.64])
	by ns-omrbm1.netsolmail.com (8.13.6/8.13.6) with SMTP id k4JLiJdo000995
	for <netconf@ops.ietf.org>; Fri, 19 May 2006 17:44:20 -0400
Received: (qmail 24400 invoked by uid 78); 19 May 2006 21:43:46 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.64 with SMTP; 19 May 2006 21:43:46 -0000
Message-ID: <446E3C0C.4030305@andybierman.com>
Date: Fri, 19 May 2006 14:43:40 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Wes Hardaker <wjhns1@hardakers.net>
CC: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, j.schoenwaelder@iu-bremen.de,
        Balazs Lengyel <balazs.lengyel@ericsson.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Scalability as requirement
References: <7D5D48D2CAA3D84C813F5B154F43B1550A13AE1E@nl0006exch001u.nl.lucent.com>	<446C8FF7.2060201@andybierman.com> <sdd5e97p8g.fsf@wes.hardakers.net>
In-Reply-To: <sdd5e97p8g.fsf@wes.hardakers.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581

Wes Hardaker wrote:
>>>>>> On Thu, 18 May 2006 08:17:11 -0700, Andy Bierman <ietf@andybierman.com> said:
> 
> Andy> Very few people have RSVPed for the interim meeting in Montreal
> Andy> as well.
> 
> I've been waiting to find an agenda (which is likely buried in
> mail)...  Is there an agenda somewhere I missed?

Not a detailed agenda yet.
The only work item is draft-ietf-netconf-notification-01.txt.


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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 19 19:40:02 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FhEZe-0002KQ-Qc
	for netconf-archive@lists.ietf.org; Fri, 19 May 2006 19:40:02 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FhEZd-0007FU-F1
	for netconf-archive@lists.ietf.org; Fri, 19 May 2006 19:40:02 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FhEUr-0008RQ-Mq
	for netconf-data@psg.com; Fri, 19 May 2006 23:35:05 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FhEUq-0008RD-Py
	for netconf@ops.ietf.org; Fri, 19 May 2006 23:35:04 +0000
Received: from mail.networksolutionsemail.com ([10.49.6.69])
	by ns-omrbm6.netsolmail.com (8.13.6/8.13.6) with SMTP id k4JNZ3JG000390
	for <netconf@ops.ietf.org>; Fri, 19 May 2006 19:35:04 -0400
Received: (qmail 3147 invoked by uid 78); 19 May 2006 23:34:50 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.69 with SMTP; 19 May 2006 23:34:50 -0000
Message-ID: <446E5613.5070607@andybierman.com>
Date: Fri, 19 May 2006 16:34:43 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: Wes Hardaker <wjhns1@hardakers.net>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        j.schoenwaelder@iu-bremen.de,
        Balazs Lengyel <balazs.lengyel@ericsson.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Scalability as requirement
References: <7D5D48D2CAA3D84C813F5B154F43B1550A13AE1E@nl0006exch001u.nl.lucent.com>	<446C8FF7.2060201@andybierman.com> <sdd5e97p8g.fsf@wes.hardakers.net> <446E3C0C.4030305@andybierman.com>
In-Reply-To: <446E3C0C.4030305@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b

Andy Bierman wrote:
> Wes Hardaker wrote:
>>>>>>> On Thu, 18 May 2006 08:17:11 -0700, Andy Bierman 
>>>>>>> <ietf@andybierman.com> said:
>>
>> Andy> Very few people have RSVPed for the interim meeting in Montreal
>> Andy> as well.
>>
>> I've been waiting to find an agenda (which is likely buried in
>> mail)...  Is there an agenda somewhere I missed?
> 
> Not a detailed agenda yet.
> The only work item is draft-ietf-netconf-notification-01.txt.
> 

At this point we need people to review the draft and comment on it.
I find it difficult to proceed or declare consensus because very
few people are participating.

We have opinions from one extreme (very important work)
to the other (waste of time) to some middle ground (nice-to-have,
not a priority).  Lots of general comments, and starting to
get some comments on specific sections...

I realize the draft is 53 pages, but there is so much
boilerplate these days, and almost nobody reads the XSD
anyway, so it's really more like 37 pages :-)

I will work on a detailed agenda/issue list by next week.


> 
> Andy

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Sun May 21 06:03:27 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FhkmV-0008Tt-CO
	for netconf-archive@lists.ietf.org; Sun, 21 May 2006 06:03:27 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FhkmS-000368-Vx
	for netconf-archive@lists.ietf.org; Sun, 21 May 2006 06:03:27 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FhkfL-0001Hd-7m
	for netconf-data@psg.com; Sun, 21 May 2006 09:56:03 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO,
	RCVD_IN_SORBS_WEB autolearn=no version=3.1.1
Received: from [64.165.72.146] (helo=dcn236-44.dcn.davis.ca.us)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <wjhns1@hardakers.net>)
	id 1FhBFx-000OBI-1p
	for netconf@ops.ietf.org; Fri, 19 May 2006 20:07:29 +0000
Received: by dcn236-44.dcn.davis.ca.us (Postfix, from userid 274)
	id CC5D411D3EE; Fri, 19 May 2006 13:07:27 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Andy Bierman <ietf@andybierman.com>
Cc: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,  j.schoenwaelder@iu-bremen.de,  Balazs Lengyel <balazs.lengyel@ericsson.com>,  "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Scalability as requirement
Organization: Sparta
References: <7D5D48D2CAA3D84C813F5B154F43B1550A13AE1E@nl0006exch001u.nl.lucent.com>
	<446C8FF7.2060201@andybierman.com>
Date: Fri, 19 May 2006 13:07:27 -0700
In-Reply-To: <446C8FF7.2060201@andybierman.com> (Andy Bierman's message of
	"Thu, 18 May 2006 08:17:11 -0700")
Message-ID: <sdd5e97p8g.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.19 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370

>>>>> On Thu, 18 May 2006 08:17:11 -0700, Andy Bierman <ietf@andybierman.com> said:

Andy> Very few people have RSVPed for the interim meeting in Montreal
Andy> as well.

I've been waiting to find an agenda (which is likely buried in
mail)...  Is there an agenda somewhere I missed?
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett



--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 22 12:44:30 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiDWA-00084a-Ab
	for netconf-archive@lists.ietf.org; Mon, 22 May 2006 12:44:30 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FiDW8-0000po-Ft
	for netconf-archive@lists.ietf.org; Mon, 22 May 2006 12:44:30 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FiDO1-000L1m-BU
	for netconf-data@psg.com; Mon, 22 May 2006 16:36:05 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS autolearn=no version=3.1.1
Received: from [216.148.227.153] (helo=rwcrmhc13.comcast.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <dbharrington@comcast.net>)
	id 1FiDNz-000L1X-6V
	for netconf@ops.ietf.org; Mon, 22 May 2006 16:36:03 +0000
Received: from harrington73653 (c-24-128-66-70.hsd1.nh.comcast.net[24.128.66.70])
          by comcast.net (rwcrmhc13) with SMTP
          id <20060522163601m1300gr5cue>; Mon, 22 May 2006 16:36:02 +0000
From: "David B Harrington" <dbharrington@comcast.net>
To: <j.schoenwaelder@iu-bremen.de>,
	"'Balazs Lengyel'" <balazs.lengyel@ericsson.com>
Cc: "'Andy Bierman'" <ietf@andybierman.com>,
	"'Netconf \(E-mail\)'" <netconf@ops.ietf.org>
Subject: RE: The datamodel in Notification Draft
Date: Mon, 22 May 2006 12:35:09 -0400
Message-ID: <08d201c67dbd$b1af8980$0400a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <20060518123448.GA8261@boskop.local>
Importance: Normal
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760

Hi,

Juergen answered this question somewhat. I agree with all his
comments. Sessions are not required for security (as USM
demonstrates), but the use of sessions can help to amortize the
overhead of transport connection and security costs over multiple
messages.

Let me discuss the ISMS solution that is in the ***current*** SSHSM
document in more detail. This is a work in progress, so things may
change. SSHSM is the SSH Security Model for SNMP.

SSMSM establishes one or more SSH sessions between an SNMP manager and
agent. Each session is based on transportType, transportAddress,
securityName (the principal or user), the securityModel (in this case
the SSH security model), and a securityLevel.=20

While SNMPv3 supports noAuthNoPriv, authPriv, and authNoPriv, SSHSM
uses only authPriv. If an application asks for a different
securitylevel, the message will still be sent over an SSH transport
connection with authentication and encryption. I expect further debate
over this approach. We decided that the details of the security
mechanisms (the authentication protocol used, the SSH protocol options
selected, etc.) should be opaque to SSHSM. Unless the SNMP engine has
more insight into and control over the SSH transport connection
parameters, and the security model violates the data hiding rules of
the RFC3411 architecture, we don't have a way to deal with multiple
securitylevels easily. Of course, an operator may choose to deploy
their SSH transport connections differently, but SSHSM will not know,
just as netconf won't know if a BEEP or SSH session is not deployed as
called for.

Sessions are reusable. It does not matter whether the session was
initially created by a manager as a request/response channel, or
created by an agent as a notifications channel. What matters is that
the transport and securityName/Model/Level match.

SSHSM sessions may be closed by either side at any time for resource
management (or other reasons). When a message is sent, the security
model in the sender checks to see if a suitable session exists. If
not, it creates an appropriate session (if it cannot, it discards the
message and sends back an error to the other parts of the engine).=20

Multiple SNMP messages, of the request/response variety or
notifications, may be sent over an existing session. SNMP messages are
BER encoded, with length tags, etc., and do not have the same issues
of document validation that a XML-based document has, and that
multiple XML messages in a stream has. So the never-ending RPC is not
an issue that has arisen in ISMS.

Just like in netconf, any callback mechanism has been underspecified.=20

In ISMS, Balsz's discussion of the loop for notifications is slightly
different because we use a modular approach:
For each event {
	determine the targets,=20
	apply filters,=20
	send message request to message processing
}
For each message request {
	build each notification,
	send message to transport mapping
}
For each message {
	Check whether suitable session exists
	If not, create session
	send message
}

Hope this helps,

David Harrington
dharrington@huawei.com=20
dbharrington@comcast.net
ietfdbh@comcast.net

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Juergen
Schoenwaelder
> Sent: Thursday, May 18, 2006 8:35 AM
> To: Balazs Lengyel
> Cc: Andy Bierman; Netconf (E-mail)
> Subject: Re: The datamodel in Notification Draft
>=20
>=20
> On Thu, May 18, 2006 at 01:59:58PM +0200, Balazs Lengyel wrote:
> =20
> > JURGEN! Could you tell us how ISMS is solving the session=20
> based security?
> > As I understand they also decided to have proper security=20
> you need to=20
> > maintain sessions.
>=20
> ISMS is all about using existing security solutions for SNMP. It
turns
> out that the most widely deployed security solutions are somehow
> session based and the most widely deployed onces are running over
> TCP. Note that session based security is not the same as running
over
> TCP.
>=20
> The statement "to have proper security you need to maintain
sessions"
> per se might not be correct. But to have security, you need to
> maintain some state between the communicating endpoints and setting
> this up involves some work, even in the case of SNMPv3/USM.
>=20
> We will soon post some measurement data to the ISMS list which shows
> the cost of the various transport and security options for SNMP. We
> did the measurements on a perfect network but also under conditions
of
> packet loss. All I can say is that those who use a stock net-snmp
> implementation really should not worry about a TCP transport in case
> the network is in trouble. With other SNMP stacks you might be
better
> off - we did not measure them.
>=20
> /js
>=20
> PS: Also SNMPv3/USM has some overhead when you send the first
>     notification and you have to synchronize clocks. You do=20
> not establish
>     a session key which saves on round trip times, but also reduces
>     the level of security you get if you are paranoid (or you have
to
>     do more frequent key changes). The point is that you have to
look
>     at the whole system and that it is misleading to separate out
>     pieces of the picture and to look at it in isolation.
>=20
> PPS: Even if you consider signed syslog messages over plain=20
> UDP, it might
>      be instructive to figure out what the overall performance will
be
>      end-to-end including generation and verification of the
>      signatures.
>=20
> --=20
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    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: <http://ops.ietf.org/lists/netconf/>
>=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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 22 13:23:48 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiE8C-0004Wl-4c
	for netconf-archive@lists.ietf.org; Mon, 22 May 2006 13:23:48 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FiE89-0002Iu-Hr
	for netconf-archive@lists.ietf.org; Mon, 22 May 2006 13:23:48 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FiE2i-000Nym-SG
	for netconf-data@psg.com; Mon, 22 May 2006 17:18:08 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FiE2g-000Nxl-NB
	for netconf@ops.ietf.org; Mon, 22 May 2006 17:18:07 +0000
Received: from mail.networksolutionsemail.com ([10.49.6.66])
	by ns-omrbm3.netsolmail.com (8.13.6/8.13.6) with SMTP id k4MHI5do031467
	for <netconf@ops.ietf.org>; Mon, 22 May 2006 13:18:05 -0400
Received: (qmail 5399 invoked by uid 78); 22 May 2006 17:15:49 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.66 with SMTP; 22 May 2006 17:15:49 -0000
Message-ID: <4471F1FE.5070902@andybierman.com>
Date: Mon, 22 May 2006 10:16:46 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: David B Harrington <dbharrington@comcast.net>
CC: j.schoenwaelder@iu-bremen.de,
        "'Balazs Lengyel'" <balazs.lengyel@ericsson.com>,
        "'Netconf (E-mail)'" <netconf@ops.ietf.org>
Subject: Re: The datamodel in Notification Draft
References: <08d201c67dbd$b1af8980$0400a8c0@china.huawei.com>
In-Reply-To: <08d201c67dbd$b1af8980$0400a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff

David B Harrington wrote:
> Hi,
> 
> Juergen answered this question somewhat. I agree with all his
> comments. Sessions are not required for security (as USM
> demonstrates), but the use of sessions can help to amortize the
> overhead of transport connection and security costs over multiple
> messages.
> 
> Let me discuss the ISMS solution that is in the ***current*** SSHSM
> document in more detail. This is a work in progress, so things may
> change. SSHSM is the SSH Security Model for SNMP.


Thank you for this summary.
It does help a lot.

One thing that seems very clear is that the IESG and many
WG participants seem intent on ignoring the NM protocol
silo proliferation problem, and in fact seem intent
on making it worse.

Now I see why notifications over netconf makes sense.
Compared to the option of using vastly different protocols,
data, and security models for every little NM task,
and if you are going down the XML path anyway -- it makes sense.


Andy


> 
> SSMSM establishes one or more SSH sessions between an SNMP manager and
> agent. Each session is based on transportType, transportAddress,
> securityName (the principal or user), the securityModel (in this case
> the SSH security model), and a securityLevel. 
> 
> While SNMPv3 supports noAuthNoPriv, authPriv, and authNoPriv, SSHSM
> uses only authPriv. If an application asks for a different
> securitylevel, the message will still be sent over an SSH transport
> connection with authentication and encryption. I expect further debate
> over this approach. We decided that the details of the security
> mechanisms (the authentication protocol used, the SSH protocol options
> selected, etc.) should be opaque to SSHSM. Unless the SNMP engine has
> more insight into and control over the SSH transport connection
> parameters, and the security model violates the data hiding rules of
> the RFC3411 architecture, we don't have a way to deal with multiple
> securitylevels easily. Of course, an operator may choose to deploy
> their SSH transport connections differently, but SSHSM will not know,
> just as netconf won't know if a BEEP or SSH session is not deployed as
> called for.
> 
> Sessions are reusable. It does not matter whether the session was
> initially created by a manager as a request/response channel, or
> created by an agent as a notifications channel. What matters is that
> the transport and securityName/Model/Level match.
> 
> SSHSM sessions may be closed by either side at any time for resource
> management (or other reasons). When a message is sent, the security
> model in the sender checks to see if a suitable session exists. If
> not, it creates an appropriate session (if it cannot, it discards the
> message and sends back an error to the other parts of the engine). 
> 
> Multiple SNMP messages, of the request/response variety or
> notifications, may be sent over an existing session. SNMP messages are
> BER encoded, with length tags, etc., and do not have the same issues
> of document validation that a XML-based document has, and that
> multiple XML messages in a stream has. So the never-ending RPC is not
> an issue that has arisen in ISMS.
> 
> Just like in netconf, any callback mechanism has been underspecified. 
> 
> In ISMS, Balsz's discussion of the loop for notifications is slightly
> different because we use a modular approach:
> For each event {
> 	determine the targets, 
> 	apply filters, 
> 	send message request to message processing
> }
> For each message request {
> 	build each notification,
> 	send message to transport mapping
> }
> For each message {
> 	Check whether suitable session exists
> 	If not, create session
> 	send message
> }
> 
> Hope this helps,
> 
> David Harrington
> dharrington@huawei.com 
> dbharrington@comcast.net
> ietfdbh@comcast.net
> 
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org 
>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Juergen
> Schoenwaelder
>> Sent: Thursday, May 18, 2006 8:35 AM
>> To: Balazs Lengyel
>> Cc: Andy Bierman; Netconf (E-mail)
>> Subject: Re: The datamodel in Notification Draft
>>
>>
>> On Thu, May 18, 2006 at 01:59:58PM +0200, Balazs Lengyel wrote:
>>  
>>> JURGEN! Could you tell us how ISMS is solving the session 
>> based security?
>>> As I understand they also decided to have proper security 
>> you need to 
>>> maintain sessions.
>> ISMS is all about using existing security solutions for SNMP. It
> turns
>> out that the most widely deployed security solutions are somehow
>> session based and the most widely deployed onces are running over
>> TCP. Note that session based security is not the same as running
> over
>> TCP.
>>
>> The statement "to have proper security you need to maintain
> sessions"
>> per se might not be correct. But to have security, you need to
>> maintain some state between the communicating endpoints and setting
>> this up involves some work, even in the case of SNMPv3/USM.
>>
>> We will soon post some measurement data to the ISMS list which shows
>> the cost of the various transport and security options for SNMP. We
>> did the measurements on a perfect network but also under conditions
> of
>> packet loss. All I can say is that those who use a stock net-snmp
>> implementation really should not worry about a TCP transport in case
>> the network is in trouble. With other SNMP stacks you might be
> better
>> off - we did not measure them.
>>
>> /js
>>
>> PS: Also SNMPv3/USM has some overhead when you send the first
>>     notification and you have to synchronize clocks. You do 
>> not establish
>>     a session key which saves on round trip times, but also reduces
>>     the level of security you get if you are paranoid (or you have
> to
>>     do more frequent key changes). The point is that you have to
> look
>>     at the whole system and that it is misleading to separate out
>>     pieces of the picture and to look at it in isolation.
>>
>> PPS: Even if you consider signed syslog messages over plain 
>> UDP, it might
>>      be instructive to figure out what the overall performance will
> be
>>      end-to-end including generation and verification of the
>>      signatures.
>>
>> -- 
>> Juergen Schoenwaelder		    International University Bremen
>> <http://www.eecs.iu-bremen.de/>	    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: <http://ops.ietf.org/lists/netconf/>
>>
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 22 15:39:36 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiGFc-0006jo-Ru
	for netconf-archive@lists.ietf.org; Mon, 22 May 2006 15:39:36 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FiGFZ-0000GG-Hg
	for netconf-archive@lists.ietf.org; Mon, 22 May 2006 15:39:36 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FiGBf-0006rM-DC
	for netconf-data@psg.com; Mon, 22 May 2006 19:35:31 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FiGBa-0006qn-L5
	for netconf@ops.ietf.org; Mon, 22 May 2006 19:35:26 +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 k4MJZN1Z080921;
	Mon, 22 May 2006 12:35:23 -0700 (PDT)
	(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 k4MJZJ552949;
	Mon, 22 May 2006 12:35:19 -0700 (PDT)
	(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 k4MJeKO4067587;
	Mon, 22 May 2006 15:40:21 -0400 (EDT)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200605221940.k4MJeKO4067587@idle.juniper.net>
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
cc: Andy Bierman <ietf@andybierman.com>,
   "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: event classes (sec. 3.5) 
In-Reply-To: Your message of "Thu, 18 May 2006 14:19:21 +0200."
             <446C6649.4070004@ericsson.com> 
Date: Mon, 22 May 2006 15:40:20 -0400
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69

Balazs Lengyel writes:
>I wonder how Juniper solved this? They had Junos-script and operational mode commands like 
>ping for a long time.

We do operational commands as simple RPCs, like:

  <ping>
    <host>10.1.2.3</host>
    <count>5</count>
    <no-resolve/>
    <interval>4</interval>
    <wait>10</wait>
  </ping>

We avoid putting actions as attributes of data.  This was done
primarily as the Junoscript API (and our netconf implementation)
leverages the existing plumbing of the UI.  The above RPC is
the equivalent of the CLI command:

    ping 10.1.2.3 count 5 no-resolve interval 4 wait 10

I continue to believe that netconf will fail if it becomes the
"third way" (where first=cli and second=snmp).  This was discussed
at length in the prelude to netconf's creation.  One of our goals
was allowing the vendor to reuse their cli implementation to the
greatest extent possible.

Given the overwhelming use of syslog and snmp to handle notifications
in the current service provider world, the idea of netconf rolling
its own notification mechanism seems to swim against this logic.

We started this notification discussion with the idea of just
carrying syslog messages over a beep channel using an existing
standard.  Have we wandered to far from this idea of reusing something
that's already there?  Will folks really revisit their entire source
code tree and code every syslog call or snmp trap creation to
generate netconf events?

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 22 17:40:32 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiI8e-0002Vw-D9
	for netconf-archive@lists.ietf.org; Mon, 22 May 2006 17:40:32 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FiI8d-0007yh-3q
	for netconf-archive@lists.ietf.org; Mon, 22 May 2006 17:40:32 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FiI5A-000EuA-W0
	for netconf-data@psg.com; Mon, 22 May 2006 21:36:56 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FiI5A-000Ety-1G
	for netconf@ops.ietf.org; Mon, 22 May 2006 21:36:56 +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 k4MLanX66076;
	Mon, 22 May 2006 14:36:49 -0700 (PDT)
	(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 k4MLah590602;
	Mon, 22 May 2006 14:36:43 -0700 (PDT)
	(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 k4MLfiO4068353;
	Mon, 22 May 2006 17:41:49 -0400 (EDT)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200605222141.k4MLfiO4068353@idle.juniper.net>
To: Andy Bierman <ietf@andybierman.com>
cc: Balazs Lengyel <balazs.lengyel@ericsson.com>,
   "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: event classes (sec. 3.5) 
In-Reply-To: Your message of "Mon, 22 May 2006 14:19:54 PDT."
             <44722AFA.5080107@andybierman.com> 
Date: Mon, 22 May 2006 17:41:44 -0400
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f

Andy Bierman writes:
>How do you distinguish delayed responses for this ping
>vs. other delayed responses. vs other RPCs?

It's a long-lived RPC.  The rpc-reply contains the entire results.

>If not that, then how do you distinguish multiple responses to
>1 request?

We don't have 'em.  It's a one-to-one mapping.

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 22 18:54:44 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiJIS-0005u4-3c
	for netconf-archive@lists.ietf.org; Mon, 22 May 2006 18:54:44 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FiI5M-0007mw-3z
	for netconf-archive@lists.ietf.org; Mon, 22 May 2006 17:37:08 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FiHrU-0007G9-Ef
	for netconf-archive@lists.ietf.org; Mon, 22 May 2006 17:22:55 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FiHnF-000Dm0-Sx
	for netconf-data@psg.com; Mon, 22 May 2006 21:18:25 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FiHnC-000Dln-6N
	for netconf@ops.ietf.org; Mon, 22 May 2006 21:18:22 +0000
Received: from mail.networksolutionsemail.com ([10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k4MLIKPH006058
	for <netconf@ops.ietf.org>; Mon, 22 May 2006 17:18:21 -0400
Received: (qmail 11995 invoked by uid 78); 22 May 2006 21:18:20 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 22 May 2006 21:18:20 -0000
Message-ID: <44722AFA.5080107@andybierman.com>
Date: Mon, 22 May 2006 14:19:54 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: Balazs Lengyel <balazs.lengyel@ericsson.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: event classes (sec. 3.5)
References: <200605221940.k4MJeKO4067587@idle.juniper.net>
In-Reply-To: <200605221940.k4MJeKO4067587@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
X-Spam-Score: -1.5 (-)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135

Phil Shafer wrote:
> Balazs Lengyel writes:
>> I wonder how Juniper solved this? They had Junos-script and operational mode commands like 
>> ping for a long time.
> 
> We do operational commands as simple RPCs, like:
> 
>   <ping>
>     <host>10.1.2.3</host>
>     <count>5</count>
>     <no-resolve/>
>     <interval>4</interval>
>     <wait>10</wait>
>   </ping>
> 

How do you distinguish delayed responses for this ping
vs. other delayed responses. vs other RPCs?
Just keep sending more <rpc-reply> messages for
the same message-id?  If so, the standard doesn't
seem to support that.

If not that, then how do you distinguish multiple responses to
1 request?

Andy



> We avoid putting actions as attributes of data.  This was done
> primarily as the Junoscript API (and our netconf implementation)
> leverages the existing plumbing of the UI.  The above RPC is
> the equivalent of the CLI command:
> 
>     ping 10.1.2.3 count 5 no-resolve interval 4 wait 10
> 
> I continue to believe that netconf will fail if it becomes the
> "third way" (where first=cli and second=snmp).  This was discussed
> at length in the prelude to netconf's creation.  One of our goals
> was allowing the vendor to reuse their cli implementation to the
> greatest extent possible.
> 
> Given the overwhelming use of syslog and snmp to handle notifications
> in the current service provider world, the idea of netconf rolling
> its own notification mechanism seems to swim against this logic.
> 
> We started this notification discussion with the idea of just
> carrying syslog messages over a beep channel using an existing
> standard.  Have we wandered to far from this idea of reusing something
> that's already there?  Will folks really revisit their entire source
> code tree and code every syslog call or snmp trap creation to
> generate netconf events?
> 
> 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: <http://ops.ietf.org/lists/netconf/>
> 
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 23 06:16:25 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiTw9-0000NI-4F
	for netconf-archive@lists.ietf.org; Tue, 23 May 2006 06:16:25 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FiTw0-0007ZN-IO
	for netconf-archive@lists.ietf.org; Tue, 23 May 2006 06:16:25 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FiTp9-000CnL-B5
	for netconf-data@psg.com; Tue, 23 May 2006 10:09:11 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FiTp5-000Cmt-8P
	for netconf@ops.ietf.org; Tue, 23 May 2006 10:09:07 +0000
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EB02078E
	for <netconf@ops.ietf.org>; Tue, 23 May 2006 12:09:05 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 23 May 2006 12:09:05 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 23 May 2006 12:09:05 +0200
Message-ID: <4472DF42.20000@ericsson.com>
Date: Tue, 23 May 2006 12:09:06 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: event classes (sec. 3.5)
References: <200605221940.k4MJeKO4067587@idle.juniper.net>
In-Reply-To: <200605221940.k4MJeKO4067587@idle.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 May 2006 10:09:05.0607 (UTC) FILETIME=[EC72D570:01C67E50]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8

Does this mean that for each operational command you have a separate RPC/operation ? How 
will you translate that to netconf ? Is the below example the complete XML doc or is there 
still some RPC wrapper around it ? Could you please send the complete XML as well.
Thanks Balazs

Phil Shafer wrote:
> Balazs Lengyel writes:
>> I wonder how Juniper solved this? They had Junos-script and operational mode commands like 
>> ping for a long time.
> 
> We do operational commands as simple RPCs, like:
> 
>   <ping>
>     <host>10.1.2.3</host>
>     <count>5</count>
>     <no-resolve/>
>     <interval>4</interval>
>     <wait>10</wait>
>   </ping>
> 
> We avoid putting actions as attributes of data.  This was done
> primarily as the Junoscript API (and our netconf implementation)
> leverages the existing plumbing of the UI.  The above RPC is
> the equivalent of the CLI command:
> 
>     ping 10.1.2.3 count 5 no-resolve interval 4 wait 10
> 
> I continue to believe that netconf will fail if it becomes the
> "third way" (where first=cli and second=snmp).  This was discussed
> at length in the prelude to netconf's creation.  One of our goals
> was allowing the vendor to reuse their cli implementation to the
> greatest extent possible.
> 
> Given the overwhelming use of syslog and snmp to handle notifications
> in the current service provider world, the idea of netconf rolling
> its own notification mechanism seems to swim against this logic.
> 
> We started this notification discussion with the idea of just
> carrying syslog messages over a beep channel using an existing
> standard.  Have we wandered to far from this idea of reusing something
> that's already there?  Will folks really revisit their entire source
> code tree and code every syslog call or snmp trap creation to
> generate netconf events?
> 
> Thanks,
>  Phil

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 23 09:11:15 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiWfL-0002uE-Mx
	for netconf-archive@lists.ietf.org; Tue, 23 May 2006 09:11:15 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FiWfK-00071A-Cu
	for netconf-archive@lists.ietf.org; Tue, 23 May 2006 09:11:15 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FiWXs-0000yB-F7
	for netconf-data@psg.com; Tue, 23 May 2006 13:03:32 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FiWXq-0000xt-6g
	for netconf@ops.ietf.org; Tue, 23 May 2006 13:03:30 +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 k4ND3SX76262;
	Tue, 23 May 2006 06:03:28 -0700 (PDT)
	(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 k4ND3M531561;
	Tue, 23 May 2006 06:03:22 -0700 (PDT)
	(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 k4ND8SO4070216;
	Tue, 23 May 2006 09:08:28 -0400 (EDT)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200605231308.k4ND8SO4070216@idle.juniper.net>
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: event classes (sec. 3.5) 
In-Reply-To: Your message of "Tue, 23 May 2006 12:09:06 +0200."
             <4472DF42.20000@ericsson.com> 
Date: Tue, 23 May 2006 09:08:28 -0400
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d

Balazs Lengyel writes:
>Does this mean that for each operational command you have a separate RPC/operation ?

Yup, under junoscript and netconf, each junos command is available
as a distinct RPC.

>Is the below example the complete XML doc or is there 
>still some RPC wrapper around it ?

What I sent was the complete RPC, as it would appear inside the
netconf <rpc> element.  Here's another example:

        <get-interface-information>
          <terse/>
          <interface-name>ge-0/1/2</interface-name>
        </get-interface-information>

All our RPCs are documented under www.juniper.net/support/junoscript/.
All these RPCs are available under netconf as well, since we drive
the command, file, patch, xml, junoscript, and netconf parsing off
the same meta-data.

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 23 11:22:35 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiYiQ-0000l8-LE
	for netconf-archive@lists.ietf.org; Tue, 23 May 2006 11:22:35 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FiYiN-0004OR-9D
	for netconf-archive@lists.ietf.org; Tue, 23 May 2006 11:22:34 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FiYc0-000BBd-Qi
	for netconf-data@psg.com; Tue, 23 May 2006 15:15:56 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FiYbx-000BB8-Qa
	for netconf@ops.ietf.org; Tue, 23 May 2006 15:15:54 +0000
Received: from mail.networksolutionsemail.com ([10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.12.10) with SMTP id k4NFFqDe003951
	for <netconf@ops.ietf.org>; Tue, 23 May 2006 11:15:53 -0400
Received: (qmail 24265 invoked by uid 78); 23 May 2006 15:15:52 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 23 May 2006 15:15:52 -0000
Message-ID: <4473270B.1030105@andybierman.com>
Date: Tue, 23 May 2006 08:15:23 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: Balazs Lengyel <balazs.lengyel@ericsson.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: event classes (sec. 3.5)
References: <200605231308.k4ND8SO4070216@idle.juniper.net>
In-Reply-To: <200605231308.k4ND8SO4070216@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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465

Phil Shafer wrote:
> Balazs Lengyel writes:
>> Does this mean that for each operational command you have a separate RPC/operation ?
> 
> Yup, under junoscript and netconf, each junos command is available
> as a distinct RPC.
> 
>> Is the below example the complete XML doc or is there 
>> still some RPC wrapper around it ?
> 
> What I sent was the complete RPC, as it would appear inside the
> netconf <rpc> element.  Here's another example:
> 
>         <get-interface-information>
>           <terse/>
>           <interface-name>ge-0/1/2</interface-name>
>         </get-interface-information>


I like special RPCs for this kind of thing.
IMO this is a different sort of RPC than the type in the
Notifications draft.   My biggest concern is not a 1000
little APIs to deal with, but rather multiple APIs that
deal with the "netconf write model" or data models
in inconsistent ways.

We have a "write model" based on 3 standard conceptual data-stores
(i.e., <candidate>, <running>, <startup>) and a set of operations
to deal with various complexities with the native devices.
IMO, defining new RPCs which modify NV-saved config data is wrong,
if they ignore or contradict this model.



> 
> All our RPCs are documented under www.juniper.net/support/junoscript/.
> All these RPCs are available under netconf as well, since we drive
> the command, file, patch, xml, junoscript, and netconf parsing off
> the same meta-data.
> 
> 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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 23 12:10:43 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiZT1-0007JV-Oi
	for netconf-archive@lists.ietf.org; Tue, 23 May 2006 12:10:43 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FiZT0-00066W-Fz
	for netconf-archive@lists.ietf.org; Tue, 23 May 2006 12:10:43 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FiZLV-000EdK-VD
	for netconf-data@psg.com; Tue, 23 May 2006 16:02:57 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FiZLV-000Ed5-9h
	for netconf@ops.ietf.org; Tue, 23 May 2006 16:02:57 +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 k4NG2s1Z099064;
	Tue, 23 May 2006 09:02:54 -0700 (PDT)
	(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 k4NG2r567936;
	Tue, 23 May 2006 09:02:53 -0700 (PDT)
	(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 k4NG7xO4070690;
	Tue, 23 May 2006 12:07:59 -0400 (EDT)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200605231607.k4NG7xO4070690@idle.juniper.net>
To: Andy Bierman <ietf@andybierman.com>
cc: Balazs Lengyel <balazs.lengyel@ericsson.com>,
   "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: event classes (sec. 3.5) 
In-Reply-To: Your message of "Tue, 23 May 2006 08:15:23 PDT."
             <4473270B.1030105@andybierman.com> 
Date: Tue, 23 May 2006 12:07:59 -0400
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2

Andy Bierman writes:
>IMO, defining new RPCs which modify NV-saved config data is wrong,
>if they ignore or contradict this model.

Yup.  The win of netconf is having a common mechanism
for dealing with configuration data.

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 23 12:27:39 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiZjP-0005hv-Ac
	for netconf-archive@lists.ietf.org; Tue, 23 May 2006 12:27:39 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FiZjO-0006Xt-0a
	for netconf-archive@lists.ietf.org; Tue, 23 May 2006 12:27:39 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FiZf6-000FrO-Lg
	for netconf-data@psg.com; Tue, 23 May 2006 16:23:12 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FiZf5-000FrB-OA
	for netconf@ops.ietf.org; Tue, 23 May 2006 16:23:12 +0000
Received: from mail.networksolutionsemail.com ([10.49.6.65])
	by ns-omrbm2.netsolmail.com (8.13.6/8.13.6) with SMTP id k4NGNAvp018849
	for <netconf@ops.ietf.org>; Tue, 23 May 2006 12:23:11 -0400
Received: (qmail 14989 invoked by uid 78); 23 May 2006 16:12:52 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 23 May 2006 16:12:52 -0000
Message-ID: <44733461.2060208@andybierman.com>
Date: Tue, 23 May 2006 09:12:17 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: Balazs Lengyel <balazs.lengyel@ericsson.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: event classes (sec. 3.5)
References: <200605222141.k4MLfiO4068353@idle.juniper.net>
In-Reply-To: <200605222141.k4MLfiO4068353@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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b

Phil Shafer wrote:
> Andy Bierman writes:
>> How do you distinguish delayed responses for this ping
>> vs. other delayed responses. vs other RPCs?
> 
> It's a long-lived RPC.  The rpc-reply contains the entire results.

Are you willing to help write an Informational RFC so those who
like it can all do long-lived RPC in the same way?

It seems to me this can make the parsing easier on the NMS, not harder.
Consider an iterator operation that get-nexts its way through really
big tables.  This is not an endless RPC, just a really long RPC
where perhaps an <ok> (to ACK the initial request) is followed by N <data>
nodes.   If the RPC is intended to end (or <abort/> is received),
the </rpc-reply> element will be sent and the PDU ended.

The difference is that instead of a really big XML tree, the NMS
can consume multiple "rows" in sequence, where each <data>
element is well-formed XML and represents a conceptually
coherent container of data. (or like, notification data even ;-)


> 
>> If not that, then how do you distinguish multiple responses to
>> 1 request?
> 
> We don't have 'em.  It's a one-to-one mapping.
> 
> 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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 23 15:21:16 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FicRQ-0001r7-Se
	for netconf-archive@lists.ietf.org; Tue, 23 May 2006 15:21:16 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FicRP-00066W-HF
	for netconf-archive@lists.ietf.org; Tue, 23 May 2006 15:21:16 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FicMA-0000z9-0C
	for netconf-data@psg.com; Tue, 23 May 2006 19:15:50 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.129.242.57] (helo=zcars04f.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <SCHISHOL@nortel.com>)
	id 1FicM8-0000ys-Cw
	for netconf@ops.ietf.org; Tue, 23 May 2006 19:15:48 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4NJFix15575;
	Tue, 23 May 2006 15:15:44 -0400 (EDT)
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: max-access: access control model discussion
Date: Tue, 23 May 2006 15:15:42 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4089DFEAE@zcarhxm2.corp.nortel.com>
In-Reply-To: <446E131D.7080905@andybierman.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: max-access: access control model discussion
Thread-Index: AcZ7deY5iMb9/AQ0R2iqQQnREu+MRADJvn6w
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>,
   "Netconf Data Model Discussion" <netconfmodel@lists.nortel.com>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b

hi

This seems much more complicated then what is in the draft. I prefer the
approach of defining a list of values rather then enumerating all the
combinations and permutations of the items in the list as unique values.


The draft considers notification another form of reading. I believe all
the other values are covered.

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Friday, May 19, 2006 2:49 PM
To: Netconf (E-mail); Netconf Data Model Discussion
Subject: max-access: access control model discussion


Hi,

This discussion is somewhat out of charter scope, but since access
control for notifications and data models keeps coming up, I think we
should discuss the basics.

IMO, the max-access mechanism in the draft is too complicated, and it
doesn't account for all operation attribute and SMI MAX-ACCESS
enumerations.  I also don't understand the preference for making the XML
as complicated as possible. I prefer simple as possible, and reusing as
much SMI as possible (without breaking netconf ;-)

Here is a snippet from the draft as an example:

 <xs:appinfo>
   <nm:minAccess><read/></nm:minAccess>
   <nm:maxAccess><read/> <write/> <create/> <delete/></nm:maxAccess>
</xs:appinfo>

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D
Here is something to throw darts at:

I have created a hierarchical max-access enumeration,
similar to the one in SMIv2, except it adds a few
enumerations for well-known 'mid-states' which can only
be defined in DESCRIPTION clauses.


The hierarchy is:

notify-only: object can appear in a /notification/data element=20
       (SMI: notify-only)

read-only: notify + object can be retrieved in any type of
       read operation  (SMI: read-only)

write-only: object can be written only if it already exists.
       No read access at all -- agent created objects for passwords,
etc.
       (SMI: write-only)

create-only: object can be created and deleted, but not edited or read.
        For passwords, etc. in dynamic objects.
        (SMI: read-create + DESCRIPTION says no read or edit if=20
rowStatus=3Dactive)

read-write: notify + read + object can be edited if it already exists
        (SMI: read-write)

read-create: notify + read + object can be created and deleted, but not=20
edited.
        (SMI: read-create + DESCRIPTION says no edit if
rowStatus=3Dactive)
        (I know this name is confusing...)

read-create-edit: notify + read + create/delete + edit
        (SMI: read-create) (alias 'all' also accepted)
 =20

Mapping to the Operation Attribute
----------------------------------

Key:  name : allowed max-access values (to permit the operation)


none : any value

merge: if object currently exists:
         write-only, read-write, all
       otherwise:
         create-only, read-create, all

replace: create-only, read-create, all

create:  create-only, read-create, all

delete: same as create


I've implemented this, and the code really is as easy
as the little table above suggests. This algorithm
treats a replace as a delete+create, so it doesn't
work for static (write-only or read-write) objects.
This keeps the code simpler, but is more restrictive.
Maybe too restrictive, I don't know yet.



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: <http://ops.ietf.org/lists/netconf/>


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 23 16:09:01 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FidBd-0005fC-Hz
	for netconf-archive@lists.ietf.org; Tue, 23 May 2006 16:09:01 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FidBa-0001QZ-7X
	for netconf-archive@lists.ietf.org; Tue, 23 May 2006 16:09:01 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fid7n-0003lI-60
	for netconf-data@psg.com; Tue, 23 May 2006 20:05:03 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fid7l-0003kc-Ur
	for netconf@ops.ietf.org; Tue, 23 May 2006 20:05:02 +0000
Received: from mail.networksolutionsemail.com ([10.49.6.65])
	by ns-omrbm2.netsolmail.com (8.13.6/8.13.6) with SMTP id k4NK51lR023300
	for <netconf@ops.ietf.org>; Tue, 23 May 2006 16:05:01 -0400
Received: (qmail 23339 invoked by uid 78); 23 May 2006 20:01:46 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 23 May 2006 20:01:46 -0000
Message-ID: <447369F7.4030102@andybierman.com>
Date: Tue, 23 May 2006 13:00:55 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>,
        Netconf Data Model Discussion <netconfmodel@lists.nortel.com>
Subject: Re: max-access: access control model discussion
References: <713043CE8B8E1348AF3C546DBE02C1B4089DFEAE@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4089DFEAE@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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca

Sharon Chisholm wrote:
> hi
> 
> This seems much more complicated then what is in the draft. I prefer the
> approach of defining a list of values rather then enumerating all the
> combinations and permutations of the items in the list as unique values.
> 
> 


What is in the draft is rather under-specified.

Forget my "extended MAX-ACCESS".  That was a mistake.
Think of the MAX-ACCESS clause exactly as defined in SMIv2 instead.

The real issue is whether the application of SMIv2 MIB modules
for use in the NETCONF protocol is of any interest whatsoever.
If so, then a mapping of the MAX-ACCESS clause to
the NETCONF protocol operations is required.
The operations 'notify' and 'read' are easy.
The other operations (merge, replace, create, delete)
are not as easy.  There are plenty of interesting
corner-cases where 'merge' and 'replace' do not behave
the same wrt/ access control (or function).

IMO, it would be better to use 1 MAX-ACCESS string
per clause, and use the enumerated values from SMIv2 MAX-ACCESS.
Normative text describing the mapping to the NETCONF protocol
is also needed. This small amount of reuse would be a step in the
right direction.



> The draft considers notification another form of reading. I believe all
> the other values are covered.


Operational experience with SNMP has shown that sometimes
there is a need to define data that is sent in a notification
but not stored in the agent as retrievable data.
That's why 'notify-only' was added to SMIv2.

> 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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 23 18:33:58 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FifRu-0007To-6y
	for netconf-archive@lists.ietf.org; Tue, 23 May 2006 18:33:58 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FifRs-0008Rb-UM
	for netconf-archive@lists.ietf.org; Tue, 23 May 2006 18:33:58 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FifMS-000B02-IS
	for netconf-data@psg.com; Tue, 23 May 2006 22:28:20 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1FifMR-000Azr-Sb
	for netconf@ops.ietf.org; Tue, 23 May 2006 22:28:20 +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 k4NMSCX92135;
	Tue, 23 May 2006 15:28:12 -0700 (PDT)
	(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 k4NMS6561511;
	Tue, 23 May 2006 15:28:06 -0700 (PDT)
	(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 k4NMX8O4071805;
	Tue, 23 May 2006 18:33:12 -0400 (EDT)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200605232233.k4NMX8O4071805@idle.juniper.net>
To: Andy Bierman <ietf@andybierman.com>
cc: Balazs Lengyel <balazs.lengyel@ericsson.com>,
   "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: event classes (sec. 3.5) 
In-Reply-To: Your message of "Tue, 23 May 2006 09:12:17 PDT."
             <44733461.2060208@andybierman.com> 
Date: Tue, 23 May 2006 18:33:07 -0400
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f

Andy Bierman writes:
>Are you willing to help write an Informational RFC so those who
>like it can all do long-lived RPC in the same way?

I've started it, but am fighting to find time to finish it.

>It seems to me this can make the parsing easier on the NMS, not harder.

Amen.  It's a simpler mechanism and reuses the existing RPC
construct.

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 24 12:57:11 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiwfX-0007Nf-Rp
	for netconf-archive@lists.ietf.org; Wed, 24 May 2006 12:57:11 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FiwfW-0001Kt-FX
	for netconf-archive@lists.ietf.org; Wed, 24 May 2006 12:57:11 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fiwa0-0004bP-7o
	for netconf-data@psg.com; Wed, 24 May 2006 16:51:28 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FiwZy-0004b7-Vr
	for netconf@ops.ietf.org; Wed, 24 May 2006 16:51:27 +0000
Received: from mail.networksolutionsemail.com ([10.49.6.65])
	by ns-omrbm2.netsolmail.com (8.13.6/8.13.6) with SMTP id k4OGpPSB023937
	for <netconf@ops.ietf.org>; Wed, 24 May 2006 12:51:26 -0400
Received: (qmail 6072 invoked by uid 78); 24 May 2006 16:45:22 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 24 May 2006 16:45:22 -0000
Message-ID: <44748DA7.7030207@andybierman.com>
Date: Wed, 24 May 2006 09:45:27 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>,
        Netconf Data Model Discussion <netconfmodel@lists.nortel.com>,
        Dan Romascanu <dromasca@avaya.com>
Subject: FYI: IPFIX XML work
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d

Hi,

I think you should read Appendix A of the IPFIX Info Model draft:

http://www.ietf.org/internet-drafts/draft-ietf-ipfix-info-11.txt

IMO, it would be a *really* bad idea for every std NM protocol with
DM info (snmp, syslog, ipfix, netconf, ?) to invent their own
DM language, module & life-cycle system, access control model,
core info model, naming model, and on and on...

Dan, I think you should force the IPFIX WG to break out (at least)
the core set of 'XML Simple Types' from this document
and let all the OPS-NM WGs review it and add/change it.
Then it should be published as a PS RFC, and all XML DM work
in the IETF must use those data types, if they apply.

By the time one figures out the "free-for-all" approach doesn't work,
it is usually too late to fix it.


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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Thu May 25 12:19:07 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FjIYF-0006Ud-5j
	for netconf-archive@lists.ietf.org; Thu, 25 May 2006 12:19:07 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FjIY5-0006d3-IA
	for netconf-archive@lists.ietf.org; Thu, 25 May 2006 12:19:07 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FjIRU-000Nm2-0g
	for netconf-data@psg.com; Thu, 25 May 2006 16:12:08 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FjIRR-000Nlm-So
	for netconf@ops.ietf.org; Thu, 25 May 2006 16:12:06 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A2FA94F0001
	for <netconf@ops.ietf.org>; Thu, 25 May 2006 18:12:04 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 25 May 2006 18:12:04 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 25 May 2006 18:12:03 +0200
Message-ID: <4475D753.4050206@ericsson.com>
Date: Thu, 25 May 2006 18:12:03 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Event classes
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 May 2006 16:12:03.0950 (UTC) FILETIME=[F62DC0E0:01C68015]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3

I wrote an alternative version of chapter 3.5 Event classes to include some comments from 
the list.

----------------------------------------------------------------------------------------
3.5  Event Classes

    Notifications can be classified into a number of event classes.  Each
    event class identifies a set of event notifications which
    - share similar content
    - are generated from similar events
    - expect similar handling on the manager/agent side
    - are used for similar purpose

    The initial set of event classes are configuration, state, rpc-reply,
    maintenance, heartbeat, fault. Netconf defines a set of standard
    event classes but allows a netconf server to use other vendor specific
    event classes if the proposed event or it's usage can not fit the
    standard classes.

    All events shall carry the following data: detailed event type,
    event class timestamp, sequence number of the notification
    and are free to carry additional data.

    For each class the following is included:
    - definition, including triggering events
    - expected handling
    - expected data, additional data is allowed
    - examples
    - why do we need the event class

    A configuration event, alternatively known as an inventory
    event, is used to indicate that hardware, software, or a
    service has been added/changed/removed.
    - As configuration notifications could potentially carry huge
    amounts of data it is expected that netconf clients will use
    filtering to reduce their number and possibly their data content.
    - The notification might carry the changed data itself or rather
    some kind of pointer to the changed part of the configuration.
    It is discouraged to include big amounts of configuration data
    in the notification or to simply repeat the content of the
    netconf operation that triggered the notification
    - Examples: HW board removed, SW module loaded, DNS server reconfigured.
    - As multiple independent sources can configure a netconf server
    node, netconf clients need to be aware of configuration operations
    issued by other clients and events like physical HW removal.

    A state event indicates a change from one state to another, where a
    state is a condition or stage in the existence of a managed entity.
    If the state can indicate some kind of fault e.g. link failed the
    notification shall be sent as a fault notification. The state
    event is not a direct result of a
    configuration operation but rather a result of a network event a
    node internal event or an indirect result of a configuration event
    - No special handling.
    - The  notification shall identify the object who's state changed
    and the new state.
    - Examples: Operational state of an interface has changed to up.
    - Internal states of a node are important for supervision purposes
    and also effect how a node can be configured.

    A maintenance event signals the beginning, process or end of an
    action generated by a manual or automated  maintenance action.
    If the maintenance event is a direct result of a
    configuration management operation on this Netconf session then
    an rpc-reply notification should be used.
    - no special handling
    - Expected data: description of the maintenance process, the stage the process
    has reached, the manual action, automatic process that triggered
    the notification
    - Examples: automatic backup completed
    - Network management needs to know about the success or failure
    of certain maintenance operations that were not triggered by the
    event receiving management entity.

    An rpc-reply event is triggered by a specific Netconf operation
    that sends back multiple response messages. The first message
    indicates the unsuccessful/successful starting of an operation
    that might take a longer time to complete. Succeeding messages
    return further results.
    - The netconf server and the management application should be
    able to link the event with the triggering operation.
    - Expected data: Reference to the triggering operation including
    session-Id and message-id, sequence number
    - Examples: end result of a long running operation, successive
    results of a ping test
    - Some operation can take a longer time to complete or produce
    multiple results in which case both an initial and one or more
    late result are needed

    A heart beat event is sent periodically to enable testing that the
    communications channel is still functional.
    - On reception the liveliness of the channel is confirmed, after
    this the notification is simply discarded not even logged.
    - Expected data: sequence number

    A fault notification is generated when a fault condition occurs.
    Depending on the severity of the fault the notification might be
    considered an alarm or a warning.
    - This notification represent an undesirable situation. It is
    expected that a manager will sooner or later take action to rectify
    the fault. The agent shall try to send the fault notification without
    any delay or buffering.
    - The fault notification should carry the following data: severity,
    event source, probable cause, specific problem, additional information
    - Examples: communications alarm, environmental alarm,
    equipment alarm, processing error alarm, quality of service alarm, or
    a threshold crossing event. See RFC3877 and RFC2819 for more
    information.
    - fault notifications are not the main aim of this configuration protocol,
    however they are included as faults have a relevance for
    configuration management.



----------------------------------------------------------------------------------------

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 26 07:32:59 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FjaYt-0008NA-J8
	for netconf-archive@lists.ietf.org; Fri, 26 May 2006 07:32:59 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FjaYs-0004ig-0s
	for netconf-archive@lists.ietf.org; Fri, 26 May 2006 07:32:59 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FjaSV-000Hw9-Qq
	for netconf-data@psg.com; Fri, 26 May 2006 11:26:23 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE,
	FORGED_RCVD_HELO,HTML_MESSAGE,RCVD_NUMERIC_HELO,SPF_PASS autolearn=no 
	version=3.1.1
Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <einarnn@cisco.com>)
	id 1FjaSU-000Hvv-Dw
	for netconf@ops.ietf.org; Fri, 26 May 2006 11:26:23 +0000
Received: from ams-core-1.cisco.com ([144.254.224.150])
  by ams-iport-1.cisco.com with ESMTP; 26 May 2006 13:26:21 +0200
Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4QBQKUE019626;
	Fri, 26 May 2006 13:26:20 +0200 (MEST)
Received: from xmb-ams-336.cisco.com ([144.254.231.81]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0);
	 Fri, 26 May 2006 13:26:19 +0200
Received: from 144.254.159.9 ([144.254.159.9]) by xmb-ams-336.emea.cisco.com ([144.254.231.81]) with Microsoft Exchange Server HTTP-DAV ;
 Fri, 26 May 2006 11:26:19 +0000
User-Agent: Microsoft-Entourage/11.2.3.060209
Date: Fri, 26 May 2006 12:26:18 +0100
Subject: Re: FYI: IPFIX XML work
From: Einar Nilsen-Nygaard <einarnn@cisco.com>
To: Andy Bierman <ietf@andybierman.com>, Netconf <netconf@ops.ietf.org>,
        Netconf Data Model Discussion <netconfmodel@lists.nortel.com>,
        Dan Romascanu <dromasca@avaya.com>
CC: "Stewart Bryant (stbryant)" <stbryant@cisco.com>,
        "Benoit Claise (bclaise)" <bclaise@cisco.com>
Message-ID: <C09CA46A.1D00E%einarnn@cisco.com>
Thread-Topic: FYI: IPFIX XML work
Thread-Index: AcZ/UsW5jFzdB2MgQ5Gob3ytN6JuHwBZG8XK
In-Reply-To: <44748DA7.7030207@andybierman.com>
Mime-version: 1.0
Content-type: multipart/alternative;
	boundary="B_3231491179_3122137"
X-OriginalArrivalTime: 26 May 2006 11:26:19.0701 (UTC) FILETIME=[35D2B650:01C680B7]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 2.1 (++)
X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3231491179_3122137
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Andy,

I agree with the concerns you express below, but I think it=B9s probably
worthwhile pointing out that the IPFIX draft is primarily targeted to
providing a machine readable definition of what already exists in the
underlying netflow records and is not defining any XML data types, simple o=
r
otherwise.

You will see from Appendix A of the draft that the data types in the =B3field=
=B2
elements go no further than high-level enum tags.

While the commonality you seek for XML schemas should be pursued, I don=B9t
see its direct relevance to the IPFIX draft you refer to, so I see no actio=
n
that needs to be pushed on the IPFIX WG until they decide to adopt some for=
m
of XML schema based approach to both describing and encoding the data they
refer to.

Cheers,

Einar

On 24/5/06 17:45, "Andy Bierman" <ietf@andybierman.com> scribbled:

> Hi,
>=20
> I think you should read Appendix A of the IPFIX Info Model draft:
>=20
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-info-11.txt
>=20
> IMO, it would be a *really* bad idea for every std NM protocol with
> DM info (snmp, syslog, ipfix, netconf, ?) to invent their own
> DM language, module & life-cycle system, access control model,
> core info model, naming model, and on and on...
>=20
> Dan, I think you should force the IPFIX WG to break out (at least)
> the core set of 'XML Simple Types' from this document
> and let all the OPS-NM WGs review it and add/change it.
> Then it should be published as a PS RFC, and all XML DM work
> in the IETF must use those data types, if they apply.
>=20
> By the time one figures out the "free-for-all" approach doesn't work,
> it is usually too late to fix it.
>=20
>=20
> Andy
>=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: <http://ops.ietf.org/lists/netconf/>
>=20


--=20
Einar Nilsen-Nygaard
Technical Leader, Cisco Systems, Inc.

It is a rare mind indeed that can render the hitherto non-existent
blindingly obvious. The cry 'I could have thought of that' is a very
popular and misleading one, for the fact is that they didn't, and a
very significant and revealing fact it is too. --Douglas Adams



--B_3231491179_3122137
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: FYI: IPFIX XML work</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:12.0px'>Andy,=
<BR>
<BR>
I agree with the concerns you express below, but I think it&#8217;s probabl=
y worthwhile pointing out that the IPFIX draft is primarily targeted to prov=
iding a machine readable definition of what already exists in the underlying=
 netflow records and is not defining any XML data types, simple or otherwise=
.<BR>
<BR>
You will see from Appendix A of the draft that the data types in the &#8220=
;field&#8221; elements go no further than high-level enum tags.<BR>
<BR>
While the commonality you seek for XML schemas should be pursued, I don&#82=
17;t see its direct relevance to the IPFIX draft you refer to, so I see no a=
ction that needs to be pushed on the IPFIX WG until they decide to adopt som=
e form of XML schema based approach to both describing and encoding the data=
 they refer to.<BR>
<BR>
Cheers,<BR>
<BR>
Einar<BR>
<BR>
On 24/5/06 17:45, &quot;Andy Bierman&quot; &lt;ietf@andybierman.com&gt; scr=
ibbled:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYL=
E=3D'font-size:12.0px'>Hi,<BR>
<BR>
I think you should read Appendix A of the IPFIX Info Model draft:<BR>
<BR>
<a href=3D"http://www.ietf.org/internet-drafts/draft-ietf-ipfix-info-11.txt">=
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-info-11.txt</a><BR>
<BR>
IMO, it would be a *really* bad idea for every std NM protocol with<BR>
DM info (snmp, syslog, ipfix, netconf, ?) to invent their own<BR>
DM language, module &amp; life-cycle system, access control model,<BR>
core info model, naming model, and on and on...<BR>
<BR>
Dan, I think you should force the IPFIX WG to break out (at least)<BR>
the core set of 'XML Simple Types' from this document<BR>
and let all the OPS-NM WGs review it and add/change it.<BR>
Then it should be published as a PS RFC, and all XML DM work<BR>
in the IETF must use those data types, if they apply.<BR>
<BR>
By the time one figures out the &quot;free-for-all&quot; approach doesn't w=
ork,<BR>
it is usually too late to fix it.<BR>
<BR>
<BR>
Andy<BR>
<BR>
<BR>
<BR>
--<BR>
to unsubscribe send a message to netconf-request@ops.ietf.org with<BR>
the word 'unsubscribe' in a single line as the message text body.<BR>
archive: <a href=3D"http://ops.ietf.org/lists/netconf/">&lt;http://ops.ietf.o=
rg/lists/netconf/&gt;</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:12.0px'><BR>
<BR>
-- <BR>
Einar Nilsen-Nygaard<BR>
Technical Leader, Cisco Systems, Inc.<BR>
<BR>
It is a rare mind indeed that can render the hitherto non-existent<BR>
blindingly obvious. The cry 'I could have thought of that' is a very<BR>
popular and misleading one, for the fact is that they didn't, and a<BR>
very significant and revealing fact it is too. --Douglas Adams<BR>
<BR>
</SPAN></FONT>
</BODY>
</HTML>


--B_3231491179_3122137--

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 26 12:36:22 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FjfIU-0007GZ-KC
	for netconf-archive@lists.ietf.org; Fri, 26 May 2006 12:36:22 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FjfIR-0005B1-2G
	for netconf-archive@lists.ietf.org; Fri, 26 May 2006 12:36:22 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FjfD6-000EZQ-D7
	for netconf-data@psg.com; Fri, 26 May 2006 16:30:48 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [205.178.146.51] (helo=omr1.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FjfD4-000EZB-SQ
	for netconf@ops.ietf.org; Fri, 26 May 2006 16:30:47 +0000
Received: from mail.networksolutionsemail.com ([10.49.6.64])
	by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k4QGUj0u004634
	for <netconf@ops.ietf.org>; Fri, 26 May 2006 12:30:45 -0400
Received: (qmail 3847 invoked by uid 78); 26 May 2006 16:30:45 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.64 with SMTP; 26 May 2006 16:30:45 -0000
Message-ID: <44772D30.8010302@andybierman.com>
Date: Fri, 26 May 2006 09:30:40 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Event classes
References: <4475D753.4050206@ericsson.com>
In-Reply-To: <4475D753.4050206@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f

Balazs Lengyel wrote:
> I wrote an alternative version of chapter 3.5 Event classes to include 
> some comments from the list.

I appreciate it.
I think it is important that the classifications
do not overlap, and the document provides clear guidelines
for selecting a classification.

Where do threshold-crossed events belong?
I think they are part of 'state events'.
It should be clear a change in state in an
embedded NM application (like RMON or ALARM-MIB)
is included in this group.

Andy


> 
> ---------------------------------------------------------------------------------------- 
> 
> 3.5  Event Classes
> 
>    Notifications can be classified into a number of event classes.  Each
>    event class identifies a set of event notifications which
>    - share similar content
>    - are generated from similar events
>    - expect similar handling on the manager/agent side
>    - are used for similar purpose
> 
>    The initial set of event classes are configuration, state, rpc-reply,
>    maintenance, heartbeat, fault. Netconf defines a set of standard
>    event classes but allows a netconf server to use other vendor specific
>    event classes if the proposed event or it's usage can not fit the
>    standard classes.
> 
>    All events shall carry the following data: detailed event type,
>    event class timestamp, sequence number of the notification
>    and are free to carry additional data.
> 
>    For each class the following is included:
>    - definition, including triggering events
>    - expected handling
>    - expected data, additional data is allowed
>    - examples
>    - why do we need the event class
> 
>    A configuration event, alternatively known as an inventory
>    event, is used to indicate that hardware, software, or a
>    service has been added/changed/removed.
>    - As configuration notifications could potentially carry huge
>    amounts of data it is expected that netconf clients will use
>    filtering to reduce their number and possibly their data content.
>    - The notification might carry the changed data itself or rather
>    some kind of pointer to the changed part of the configuration.
>    It is discouraged to include big amounts of configuration data
>    in the notification or to simply repeat the content of the
>    netconf operation that triggered the notification
>    - Examples: HW board removed, SW module loaded, DNS server reconfigured.
>    - As multiple independent sources can configure a netconf server
>    node, netconf clients need to be aware of configuration operations
>    issued by other clients and events like physical HW removal.
> 
>    A state event indicates a change from one state to another, where a
>    state is a condition or stage in the existence of a managed entity.
>    If the state can indicate some kind of fault e.g. link failed the
>    notification shall be sent as a fault notification. The state
>    event is not a direct result of a
>    configuration operation but rather a result of a network event a
>    node internal event or an indirect result of a configuration event
>    - No special handling.
>    - The  notification shall identify the object who's state changed
>    and the new state.
>    - Examples: Operational state of an interface has changed to up.
>    - Internal states of a node are important for supervision purposes
>    and also effect how a node can be configured.
> 
>    A maintenance event signals the beginning, process or end of an
>    action generated by a manual or automated  maintenance action.
>    If the maintenance event is a direct result of a
>    configuration management operation on this Netconf session then
>    an rpc-reply notification should be used.
>    - no special handling
>    - Expected data: description of the maintenance process, the stage 
> the process
>    has reached, the manual action, automatic process that triggered
>    the notification
>    - Examples: automatic backup completed
>    - Network management needs to know about the success or failure
>    of certain maintenance operations that were not triggered by the
>    event receiving management entity.
> 
>    An rpc-reply event is triggered by a specific Netconf operation
>    that sends back multiple response messages. The first message
>    indicates the unsuccessful/successful starting of an operation
>    that might take a longer time to complete. Succeeding messages
>    return further results.
>    - The netconf server and the management application should be
>    able to link the event with the triggering operation.
>    - Expected data: Reference to the triggering operation including
>    session-Id and message-id, sequence number
>    - Examples: end result of a long running operation, successive
>    results of a ping test
>    - Some operation can take a longer time to complete or produce
>    multiple results in which case both an initial and one or more
>    late result are needed
> 
>    A heart beat event is sent periodically to enable testing that the
>    communications channel is still functional.
>    - On reception the liveliness of the channel is confirmed, after
>    this the notification is simply discarded not even logged.
>    - Expected data: sequence number
> 
>    A fault notification is generated when a fault condition occurs.
>    Depending on the severity of the fault the notification might be
>    considered an alarm or a warning.
>    - This notification represent an undesirable situation. It is
>    expected that a manager will sooner or later take action to rectify
>    the fault. The agent shall try to send the fault notification without
>    any delay or buffering.
>    - The fault notification should carry the following data: severity,
>    event source, probable cause, specific problem, additional information
>    - Examples: communications alarm, environmental alarm,
>    equipment alarm, processing error alarm, quality of service alarm, or
>    a threshold crossing event. See RFC3877 and RFC2819 for more
>    information.
>    - fault notifications are not the main aim of this configuration 
> protocol,
>    however they are included as faults have a relevance for
>    configuration management.
> 
> 
> 
> ---------------------------------------------------------------------------------------- 
> 
> 
> -- 
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 26 15:36:12 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fji6W-0003so-VE
	for netconf-archive@lists.ietf.org; Fri, 26 May 2006 15:36:12 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fji6U-0002lW-In
	for netconf-archive@lists.ietf.org; Fri, 26 May 2006 15:36:12 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fji22-0003j1-05
	for netconf-data@psg.com; Fri, 26 May 2006 19:31:34 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fji20-0003iq-CB
	for netconf@ops.ietf.org; Fri, 26 May 2006 19:31:33 +0000
Received: from mail.networksolutionsemail.com ([10.49.6.65])
	by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k4QJVU2E031979
	for <netconf@ops.ietf.org>; Fri, 26 May 2006 15:31:31 -0400
Received: (qmail 27268 invoked by uid 78); 26 May 2006 19:28:21 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 26 May 2006 19:28:21 -0000
Message-ID: <447756CF.1050205@andybierman.com>
Date: Fri, 26 May 2006 12:28:15 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: more fun with the operation attribute
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44

Hi,

The processing model (and sequence) within a netconf PDU is not
actually defined.  I believe our term for it is 'data-model specific'.
The problem is that our data modeling language(s) don't really
provide any help here.

Consider this PDU, where the <users> table is allowed to have one entry
per each value of the key (name).  In the target data model, the <users>
container exists, but is empty.

<rpc message-id="101">
<edit-config>
  ...
  <config>
    <users>
      <user operation="create">
        <name>fred</name>
        <type>admin</admin>
      </user>
      <user operation="create">
        <name>fred</name>
        <type>admin</admin>
      </user>
      <user operation="create">
        <name>fred</name>
        <type>guest</admin>
      </user>
      <user operation="merge">
        <name>fred</name>
        <type>admin</admin>
      </user>
      <user operation="replace">
        <name>fred</name>
        <type>staff</admin>
      </user>
    </users>
  </config>
</edit-config>
</rpc>

Remember that we have no "as-if-simultaneous" rules in netconf
like in snmp.  AFAIK, we don't have any rules that explicitly
permit or prohibit this.  Nor do we have any clue what the
standard result of the operation would be after this RPC,
if it did succeed.  That is also data-model specific.

Don't you love corner-cases?
So what should the proper standard response to this PDU be, if any?


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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 26 17:24:01 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fjjmr-0002tR-Ke
	for netconf-archive@lists.ietf.org; Fri, 26 May 2006 17:24:01 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FjjjK-0006Wm-1x
	for netconf-archive@lists.ietf.org; Fri, 26 May 2006 17:20:23 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fjjf0-000BFh-QA
	for netconf-data@psg.com; Fri, 26 May 2006 21:15:54 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1Fjjf0-000BFV-4V
	for netconf@ops.ietf.org; Fri, 26 May 2006 21:15:54 +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 k4QLFmX40174;
	Fri, 26 May 2006 14:15:48 -0700 (PDT)
	(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 k4QLFg583391;
	Fri, 26 May 2006 14:15:43 -0700 (PDT)
	(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 k4QLKlO4082890;
	Fri, 26 May 2006 17:20:48 -0400 (EDT)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200605262120.k4QLKlO4082890@idle.juniper.net>
To: Andy Bierman <ietf@andybierman.com>
cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: more fun with the operation attribute 
In-Reply-To: Your message of "Fri, 26 May 2006 12:28:15 PDT."
             <447756CF.1050205@andybierman.com> 
Date: Fri, 26 May 2006 17:20:47 -0400
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad

Andy Bierman writes:
>So what should the proper standard response to this PDU be, if any?

IMHO, create, merge, and replace should all succeed if the target
doesn't exist.

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Fri May 26 18:12:16 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FjkXY-0002Ui-Nl
	for netconf-archive@lists.ietf.org; Fri, 26 May 2006 18:12:16 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FjkXV-0005PT-Cc
	for netconf-archive@lists.ietf.org; Fri, 26 May 2006 18:12:16 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FjkUY-000Ep6-2v
	for netconf-data@psg.com; Fri, 26 May 2006 22:09:10 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=omr3.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FjkUX-000Eou-2G
	for netconf@ops.ietf.org; Fri, 26 May 2006 22:09:09 +0000
Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66])
	by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k4QM97FS029533
	for <netconf@ops.ietf.org>; Fri, 26 May 2006 18:09:08 -0400
Received: (qmail 1477 invoked by uid 78); 26 May 2006 22:09:07 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.66 with SMTP; 26 May 2006 22:09:07 -0000
Message-ID: <44777C7F.7050905@andybierman.com>
Date: Fri, 26 May 2006 15:09:03 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: more fun with the operation attribute
References: <200605262120.k4QLKlO4082890@idle.juniper.net>
In-Reply-To: <200605262120.k4QLKlO4082890@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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b

Phil Shafer wrote:
> Andy Bierman writes:
>> So what should the proper standard response to this PDU be, if any?
> 
> IMHO, create, merge, and replace should all succeed if the target
> doesn't exist.

Yes, but that is clear if the create, merge, of replace operation
is by itself and the target does not exist.

In this case, they are all part of one request.
The data modeling languages describe what a valid
datastore (PDU result) on the agent should look like.
In this case, it just says the key to the <user> 'table'
is the <name> child element.

A sequential CLI model would allow this PDU, (w/o
the cut-and-paste end-tag errors that is) and the
final result would be "last one wins". In this case,
that means the 'replace' node would be the one that
actually sets the user entry for 'fred'.

Are there use cases where a different result makes operational sense?
If not, can we try to standardize this behavior to
mean "last one wins" (when multiple valid operations for the same
data element are attempted).

> 
> 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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Sun May 28 14:21:06 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FkPsw-0002QN-AB
	for netconf-archive@lists.ietf.org; Sun, 28 May 2006 14:21:06 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FkPsu-0007OM-Uc
	for netconf-archive@lists.ietf.org; Sun, 28 May 2006 14:21:06 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FkPnW-000LUG-Ja
	for netconf-data@psg.com; Sun, 28 May 2006 18:15:30 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FkPnV-000LU4-Am
	for netconf@ops.ietf.org; Sun, 28 May 2006 18:15:29 +0000
Received: from mail.networksolutionsemail.com (ns-omr1.mgt.netsol.com [10.49.6.64])
	by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k4SIFS27024544
	for <netconf@ops.ietf.org>; Sun, 28 May 2006 14:15:28 -0400
Received: (qmail 1497 invoked by uid 78); 28 May 2006 18:15:28 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.64 with SMTP; 28 May 2006 18:15:28 -0000
Message-ID: <4479E8BA.1010308@andybierman.com>
Date: Sun, 28 May 2006 11:15:22 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>, Phil Shafer <phil@juniper.net>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: subtree filter spec vs. implementation
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4

Hi,

Does the Juniper implementation of subtree filtering work
as literally defined in the spec, or more as a boolean filter?

In our usual example, let's say the <users> container exists,
and the user issues a get-config command:

----------------------------------------------------------------------------

  <rpc message-id="101" xmlns="netconf-blah">
    <get-config>
      <source><running/></source>
      <filter type="subtree">
        <top xmlns="example.com-blah">
          <users>
            <user>
              <name>fred</name>
            </user>
          </users>
        </top>
      </filter>
    </get-config>
  </rpc>


According to the spec (as Martin and I understand it)
there are 3 possible outcomes here (assuming read access is granted):

1) If <users> is empty:

  <rpc-reply message-id="101" xmlns="netconf-blah">
    <data>
      <top xmlns="example.com-blah">
        <users/>
      </top>
    </data>
  </rpc-reply>

2) If <users> is not empty, but entry for 'fred' does not exist:

  <rpc-reply message-id="101" xmlns="netconf-blah">
    <data>
      <top xmlns="example.com-blah">
        <users>
          <user/>
        </users>
      </top>
    </data>
  </rpc-reply>

3) Entry for 'fred' exists

  <rpc-reply message-id="101" xmlns="netconf-blah">
    <data>
      <top xmlns="example.com-blah">
        <users>
          <user>
            <name>fred</name>
            <type>admin</type>
          </user>
        </users>
      </top>
    </data>
  </rpc-reply>

-------------------------------------------------------------------------

So is this how Juniper (and others) are implementing subtree filtering?
If so, it is clearly useless for notification content filtering.
But there is minor operational value in knowing (1) or (2) vs.
knowing (3) or nothing.  IMO, not enough to justify implementing
subtree filtering this way though.

For cases (1) and (2) I believe the XMLCONF design team envisioned
this response:

  <rpc-reply message-id="101" xmlns="netconf-blah">
    <data/>
  </rpc-reply>

However, this response is incorrect according to the spec.
I would like to converge on the standard behavior of details
like this ASAP.

<soapbox>
I cannot over-stress how important it is from an NMS POV that
the netconf standard provide a CONSISTENT programming interface.
There must be a clear distinction between the "window to the native CLI"
concept and standard behavior. Subtree filtering needs to be 
inter-operable,
or it will be removed when the protocol is evaluated for
standards-track advancement.)
</soapbox>


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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 29 04:43:22 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FkdLO-00070D-DL
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 04:43:22 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FkdLI-0003AJ-S5
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 04:43:22 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FkdCR-0002Uy-JN
	for netconf-data@psg.com; Mon, 29 May 2006 08:34:07 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FkdCN-0002Sz-3V
	for netconf@ops.ietf.org; Mon, 29 May 2006 08:34:03 +0000
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E7B4C870;
	Mon, 29 May 2006 10:34:01 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 29 May 2006 10:34:01 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 29 May 2006 10:34:00 +0200
Message-ID: <447AB1F9.8060205@ericsson.com>
Date: Mon, 29 May 2006 10:34:01 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Event classes
References: <4475D753.4050206@ericsson.com> <44772D30.8010302@andybierman.com>
In-Reply-To: <44772D30.8010302@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 May 2006 08:34:00.0663 (UTC) FILETIME=[A283F670:01C682FA]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21be852dc93f0971708678c18d38c096

Hello,
State is a good choice but there is a more general issue hidden here.

State events can also represent a fault. E.g. For threshold-crossing: memory-usage more 
then 20% is just a state event. Memory usage more then 99.9% is a critical fault/alarm as 
at this point we can easily have a crash. Where do we put such events? Shall we
- allow such events to jump from state to fault depending on the seriousness of the situation
- allow some notifications to belong to more then one event class
- leave it to the application developer
regards Balazs

Andy Bierman wrote:
> Balazs Lengyel wrote:
>> I wrote an alternative version of chapter 3.5 Event classes to include 
>> some comments from the list.
> 
> I appreciate it.
> I think it is important that the classifications
> do not overlap, and the document provides clear guidelines
> for selecting a classification.
> 
> Where do threshold-crossed events belong?
> I think they are part of 'state events'.
> It should be clear a change in state in an
> embedded NM application (like RMON or ALARM-MIB)
> is included in this group.
> 
> Andy
> 
> 
>>
>> ---------------------------------------------------------------------------------------- 
>>
>> 3.5  Event Classes
>>
>>    Notifications can be classified into a number of event classes.  Each
>>    event class identifies a set of event notifications which
>>    - share similar content
>>    - are generated from similar events
>>    - expect similar handling on the manager/agent side
>>    - are used for similar purpose
>>
>>    The initial set of event classes are configuration, state, rpc-reply,
>>    maintenance, heartbeat, fault. Netconf defines a set of standard
>>    event classes but allows a netconf server to use other vendor specific
>>    event classes if the proposed event or it's usage can not fit the
>>    standard classes.
>>
>>    All events shall carry the following data: detailed event type,
>>    event class timestamp, sequence number of the notification
>>    and are free to carry additional data.
>>
>>    For each class the following is included:
>>    - definition, including triggering events
>>    - expected handling
>>    - expected data, additional data is allowed
>>    - examples
>>    - why do we need the event class
>>
>>    A configuration event, alternatively known as an inventory
>>    event, is used to indicate that hardware, software, or a
>>    service has been added/changed/removed.
>>    - As configuration notifications could potentially carry huge
>>    amounts of data it is expected that netconf clients will use
>>    filtering to reduce their number and possibly their data content.
>>    - The notification might carry the changed data itself or rather
>>    some kind of pointer to the changed part of the configuration.
>>    It is discouraged to include big amounts of configuration data
>>    in the notification or to simply repeat the content of the
>>    netconf operation that triggered the notification
>>    - Examples: HW board removed, SW module loaded, DNS server 
>> reconfigured.
>>    - As multiple independent sources can configure a netconf server
>>    node, netconf clients need to be aware of configuration operations
>>    issued by other clients and events like physical HW removal.
>>
>>    A state event indicates a change from one state to another, where a
>>    state is a condition or stage in the existence of a managed entity.
>>    If the state can indicate some kind of fault e.g. link failed the
>>    notification shall be sent as a fault notification. The state
>>    event is not a direct result of a
>>    configuration operation but rather a result of a network event a
>>    node internal event or an indirect result of a configuration event
>>    - No special handling.
>>    - The  notification shall identify the object who's state changed
>>    and the new state.
>>    - Examples: Operational state of an interface has changed to up.
>>    - Internal states of a node are important for supervision purposes
>>    and also effect how a node can be configured.
>>
>>    A maintenance event signals the beginning, process or end of an
>>    action generated by a manual or automated  maintenance action.
>>    If the maintenance event is a direct result of a
>>    configuration management operation on this Netconf session then
>>    an rpc-reply notification should be used.
>>    - no special handling
>>    - Expected data: description of the maintenance process, the stage 
>> the process
>>    has reached, the manual action, automatic process that triggered
>>    the notification
>>    - Examples: automatic backup completed
>>    - Network management needs to know about the success or failure
>>    of certain maintenance operations that were not triggered by the
>>    event receiving management entity.
>>
>>    An rpc-reply event is triggered by a specific Netconf operation
>>    that sends back multiple response messages. The first message
>>    indicates the unsuccessful/successful starting of an operation
>>    that might take a longer time to complete. Succeeding messages
>>    return further results.
>>    - The netconf server and the management application should be
>>    able to link the event with the triggering operation.
>>    - Expected data: Reference to the triggering operation including
>>    session-Id and message-id, sequence number
>>    - Examples: end result of a long running operation, successive
>>    results of a ping test
>>    - Some operation can take a longer time to complete or produce
>>    multiple results in which case both an initial and one or more
>>    late result are needed
>>
>>    A heart beat event is sent periodically to enable testing that the
>>    communications channel is still functional.
>>    - On reception the liveliness of the channel is confirmed, after
>>    this the notification is simply discarded not even logged.
>>    - Expected data: sequence number
>>
>>    A fault notification is generated when a fault condition occurs.
>>    Depending on the severity of the fault the notification might be
>>    considered an alarm or a warning.
>>    - This notification represent an undesirable situation. It is
>>    expected that a manager will sooner or later take action to rectify
>>    the fault. The agent shall try to send the fault notification without
>>    any delay or buffering.
>>    - The fault notification should carry the following data: severity,
>>    event source, probable cause, specific problem, additional information
>>    - Examples: communications alarm, environmental alarm,
>>    equipment alarm, processing error alarm, quality of service alarm, or
>>    a threshold crossing event. See RFC3877 and RFC2819 for more
>>    information.
>>    - fault notifications are not the main aim of this configuration 
>> protocol,
>>    however they are included as faults have a relevance for
>>    configuration management.
>>
>>
>>
>> ---------------------------------------------------------------------------------------- 
>>
>>
>> -- 
>> to unsubscribe send a message to netconf-request@ops.ietf.org with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
>>
>>
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 29 08:49:01 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FkhB7-0006Ya-8d
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 08:49:01 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FkhB5-00025P-Ug
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 08:49:01 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fkh4y-000M42-QI
	for netconf-data@psg.com; Mon, 29 May 2006 12:42:40 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <phil@juniper.net>)
	id 1Fkh4y-000M3p-4Y
	for netconf@ops.ietf.org; Mon, 29 May 2006 12:42:40 +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 k4TCgc1Z060428;
	Mon, 29 May 2006 05:42:38 -0700 (PDT)
	(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 k4TCgb556291;
	Mon, 29 May 2006 05:42:38 -0700 (PDT)
	(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 k4TClbO4090168;
	Mon, 29 May 2006 08:47:41 -0400 (EDT)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200605291247.k4TClbO4090168@idle.juniper.net>
To: Andy Bierman <ietf@andybierman.com>
cc: Martin Bjorklund <mbj@tail-f.com>,
   "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: subtree filter spec vs. implementation 
In-Reply-To: Your message of "Sun, 28 May 2006 11:15:22 PDT."
             <4479E8BA.1010308@andybierman.com> 
Date: Mon, 29 May 2006 08:47:37 -0400
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe

Andy Bierman writes:
>1) If <users> is empty:
>2) If <users> is not empty, but entry for 'fred' does not exist:

Both of these cases return an empty <configuration> element.
Filtering on something that isn't there gets you nothing.

    <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/8.0I0/junos">
      <data>
        <configuration>
        </configuration>
      </data>
    </rpc-reply>

>3) Entry for 'fred' exists

    <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/8.0I0/junos">
      <data>
        <configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm">
          <system>
            <login>
              <user>
                <name>phil</name>
                <full-name>Phil Shafer</full-name>
                <uid>1089</uid>
                <class>super-user</class>
                <authentication>
                  <encrypted-password>$1$mumblemumble</encrypted-password>
                    <ssh-dsa>
                      <name>ssh-dss XYZZY</name>
                    </ssh-dsa>
                </authentication>
              </user>
            </login>
          </system>
        </configuration>
      </data>
    </rpc-reply>

>For cases (1) and (2) I believe the XMLCONF design team envisioned
>this response:
>  <rpc-reply message-id="101" xmlns="netconf-blah">
>    <data/>
>  </rpc-reply>

Yup, exactly what I recall as well.

>However, this response is incorrect according to the spec.

This is bad news.  Can we issue an errata for a spec?

>I would like to converge on the standard behavior of details
>like this ASAP.

Amen.

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 29 10:08:05 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FkiPd-00017z-C2
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 10:08:05 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FkiPb-0002AC-Vv
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 10:08:05 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FkiLN-0002k8-L1
	for netconf-data@psg.com; Mon, 29 May 2006 14:03:41 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <SCHISHOL@nortel.com>)
	id 1FkiLL-0002jq-KC
	for netconf@ops.ietf.org; Mon, 29 May 2006 14:03:39 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4TE3aJ20748;
	Mon, 29 May 2006 10:03:36 -0400 (EDT)
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: max-access: access control model discussion
Date: Mon, 29 May 2006 10:03:34 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B408B1E1F4@zcarhxm2.corp.nortel.com>
In-Reply-To: <LYRIS-38962-603484-2006.05.23-16.05.12--schishol#nortel.com@ztcfd0k3.ca.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: max-access: access control model discussion
Thread-Index: AcZ+pHVaU5kktSn3R62UZGQjEia/QQEg8X1g
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf Data Model Discussion" <netconfmodel@lists.nortel.com>,
   "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4

hi

I don't think there is any requirement to support a mapping of the SMIv2
max-access clause in Netconf. What there is a requirement to be able to
specify which operations make operational for a particular data element.
We should define this to be only what we need for Netconf.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]=20
Sent: Tuesday, May 23, 2006 4:01 PM
To: Netconf Data Model Discussion
Cc: Netconf (E-mail); Netconf Data Model Discussion
Subject: Re: max-access: access control model discussion


Sharon Chisholm wrote:
> hi
>=20
> This seems much more complicated then what is in the draft. I prefer=20
> the approach of defining a list of values rather then enumerating all=20
> the combinations and permutations of the items in the list as unique=20
> values.
>=20
>=20


What is in the draft is rather under-specified.

Forget my "extended MAX-ACCESS".  That was a mistake.
Think of the MAX-ACCESS clause exactly as defined in SMIv2 instead.

The real issue is whether the application of SMIv2 MIB modules for use
in the NETCONF protocol is of any interest whatsoever. If so, then a
mapping of the MAX-ACCESS clause to the NETCONF protocol operations is
required. The operations 'notify' and 'read' are easy. The other
operations (merge, replace, create, delete) are not as easy.  There are
plenty of interesting corner-cases where 'merge' and 'replace' do not
behave the same wrt/ access control (or function).

IMO, it would be better to use 1 MAX-ACCESS string
per clause, and use the enumerated values from SMIv2 MAX-ACCESS.
Normative text describing the mapping to the NETCONF protocol is also
needed. This small amount of reuse would be a step in the right
direction.



> The draft considers notification another form of reading. I believe=20
> all the other values are covered.


Operational experience with SNMP has shown that sometimes
there is a need to define data that is sent in a notification but not
stored in the agent as retrievable data. That's why 'notify-only' was
added to SMIv2.

> 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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 29 10:13:27 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FkiUp-0003Bf-7s
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 10:13:27 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FkiUn-0002hX-RX
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 10:13:27 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FkiQN-0003IV-Jy
	for netconf-data@psg.com; Mon, 29 May 2006 14:08:51 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <SCHISHOL@nortel.com>)
	id 1FkiQM-0003II-QP
	for netconf@ops.ietf.org; Mon, 29 May 2006 14:08:51 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4TE8lJ21328;
	Mon, 29 May 2006 10:08:48 -0400 (EDT)
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: max-access: access control model discussion
Date: Mon, 29 May 2006 10:08:44 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B408B1E210@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: max-access: access control model discussion
Thread-Index: AcZ+pHVaU5kktSn3R62UZGQjEia/QQEg8X1gAAAnTUA=
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf Data Model Discussion" <netconfmodel@lists.nortel.com>,
   "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be

hi

Oh, and I should note that in SNMP MIB consulting I strongly advised
against people using accessible-for-notify parameters. These cause a lot
of problems when used, most notably trying to transition to a case where
you realize that actually you do want to be able to poll this
information.

I'd prefer we not reproduce this 'feature' in Netconf.

Sharon

-----Original Message-----
From: Chisholm, Sharon [CAR:ZZ00:EXCH]=20
Sent: Monday, May 29, 2006 10:04 AM
To: 'Netconf Data Model Discussion'; 'Netconf (E-mail)'
Subject: RE: max-access: access control model discussion


hi

I don't think there is any requirement to support a mapping of the SMIv2
max-access clause in Netconf. What there is a requirement to be able to
specify which operations make operational for a particular data element.
We should define this to be only what we need for Netconf.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]=20
Sent: Tuesday, May 23, 2006 4:01 PM
To: Netconf Data Model Discussion
Cc: Netconf (E-mail); Netconf Data Model Discussion
Subject: Re: max-access: access control model discussion


Sharon Chisholm wrote:
> hi
>=20
> This seems much more complicated then what is in the draft. I prefer
> the approach of defining a list of values rather then enumerating all=20
> the combinations and permutations of the items in the list as unique=20
> values.
>=20
>=20


What is in the draft is rather under-specified.

Forget my "extended MAX-ACCESS".  That was a mistake.
Think of the MAX-ACCESS clause exactly as defined in SMIv2 instead.

The real issue is whether the application of SMIv2 MIB modules for use
in the NETCONF protocol is of any interest whatsoever. If so, then a
mapping of the MAX-ACCESS clause to the NETCONF protocol operations is
required. The operations 'notify' and 'read' are easy. The other
operations (merge, replace, create, delete) are not as easy.  There are
plenty of interesting corner-cases where 'merge' and 'replace' do not
behave the same wrt/ access control (or function).

IMO, it would be better to use 1 MAX-ACCESS string
per clause, and use the enumerated values from SMIv2 MAX-ACCESS.
Normative text describing the mapping to the NETCONF protocol is also
needed. This small amount of reuse would be a step in the right
direction.



> The draft considers notification another form of reading. I believe
> all the other values are covered.


Operational experience with SNMP has shown that sometimes
there is a need to define data that is sent in a notification but not
stored in the agent as retrievable data. That's why 'notify-only' was
added to SMIv2.

> 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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 29 10:18:08 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FkiZM-00062U-4a
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 10:18:08 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FkiZK-0002n8-Pv
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 10:18:08 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FkiW2-0003oV-Le
	for netconf-data@psg.com; Mon, 29 May 2006 14:14:42 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.55] (helo=omr5.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FkiVz-0003o7-Ha
	for netconf@ops.ietf.org; Mon, 29 May 2006 14:14:39 +0000
Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68])
	by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k4TEEcvZ015559
	for <netconf@ops.ietf.org>; Mon, 29 May 2006 10:14:39 -0400
Received: (qmail 24161 invoked by uid 78); 29 May 2006 14:14:38 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.68 with SMTP; 29 May 2006 14:14:38 -0000
Message-ID: <447B01C8.8060303@andybierman.com>
Date: Mon, 29 May 2006 07:14:32 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: Martin Bjorklund <mbj@tail-f.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: subtree filter spec vs. implementation
References: <200605291247.k4TClbO4090168@idle.juniper.net>
In-Reply-To: <200605291247.k4TClbO4090168@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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6

Phil Shafer wrote:
> Andy Bierman writes:
>> 1) If <users> is empty:
>> 2) If <users> is not empty, but entry for 'fred' does not exist:
> 
> Both of these cases return an empty <configuration> element.
> Filtering on something that isn't there gets you nothing.


This is not how the netconf standard is defined.
Your code is non-compliant.   :-(


> 
>     <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/8.0I0/junos">
>       <data>
>         <configuration>
>         </configuration>
>       </data>
>     </rpc-reply>
> 
>> 3) Entry for 'fred' exists
> 
>     <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/8.0I0/junos">
>       <data>
>         <configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm">
>           <system>
>             <login>
>               <user>
>                 <name>phil</name>
>                 <full-name>Phil Shafer</full-name>
>                 <uid>1089</uid>
>                 <class>super-user</class>
>                 <authentication>
>                   <encrypted-password>$1$mumblemumble</encrypted-password>
>                     <ssh-dsa>
>                       <name>ssh-dss XYZZY</name>
>                     </ssh-dsa>
>                 </authentication>
>               </user>
>             </login>
>           </system>
>         </configuration>
>       </data>
>     </rpc-reply>
> 
>> For cases (1) and (2) I believe the XMLCONF design team envisioned
>> this response:
>>  <rpc-reply message-id="101" xmlns="netconf-blah">
>>    <data/>
>>  </rpc-reply>
> 
> Yup, exactly what I recall as well.
> 
>> However, this response is incorrect according to the spec.
> 
> This is bad news.  Can we issue an errata for a spec?

I hope so.
We need to agree on the text.
I searched some old drafts and could not find my
original sentence regarding removal of dead-end sub-trees.

FWIW, I think it is about the same amount of work
to implement subtree filtering either way.


> 
>> I would like to converge on the standard behavior of details
>> like this ASAP.
> 
> Amen.
> 
> 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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 29 10:58:58 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FkjCs-0001zx-Qs
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 10:58:58 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FkjCn-0004h4-8K
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 10:58:58 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fkj9M-0006a5-Qr
	for netconf-data@psg.com; Mon, 29 May 2006 14:55:20 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fkj9M-0006Zh-1l
	for netconf@ops.ietf.org; Mon, 29 May 2006 14:55:20 +0000
Received: from mail.networksolutionsemail.com (ns-omr1.mgt.netsol.com [10.49.6.64])
	by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k4TEss3j014079
	for <netconf@ops.ietf.org>; Mon, 29 May 2006 10:55:00 -0400
Received: (qmail 14980 invoked by uid 78); 29 May 2006 14:17:56 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.64 with SMTP; 29 May 2006 14:17:56 -0000
Message-ID: <447B028E.4000104@andybierman.com>
Date: Mon, 29 May 2006 07:17:50 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: Netconf Data Model Discussion <netconfmodel@lists.nortel.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: max-access: access control model discussion
References: <713043CE8B8E1348AF3C546DBE02C1B408B1E1F4@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B408B1E1F4@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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007

Sharon Chisholm wrote:
> hi
> 
> I don't think there is any requirement to support a mapping of the SMIv2
> max-access clause in Netconf. What there is a requirement to be able to
> specify which operations make operational for a particular data element.
> We should define this to be only what we need for Netconf.

No requirement.
As I said, it is only important if one ever plans to reuse
any SMIv2 data models in NETCONF.  If you are planning on
ignoring almost two decades of IETF data modeling work,
this is not important.


> 
> 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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 29 11:39:57 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FkjqX-0000hK-0c
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 11:39:57 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FkjqR-0000ZZ-MJ
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 11:39:56 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fkjn9-0009OB-Jr
	for netconf-data@psg.com; Mon, 29 May 2006 15:36:27 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1Fkjn8-0009Nw-Go
	for netconf@ops.ietf.org; Mon, 29 May 2006 15:36:26 +0000
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7239F4F0055
	for <netconf@ops.ietf.org>; Mon, 29 May 2006 17:36:25 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 29 May 2006 17:36:24 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 29 May 2006 17:36:24 +0200
Message-ID: <447B14F7.1000305@ericsson.com>
Date: Mon, 29 May 2006 17:36:23 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: max-access: access control model discussion
References: <446E131D.7080905@andybierman.com>
In-Reply-To: <446E131D.7080905@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 May 2006 15:36:24.0279 (UTC) FILETIME=[A47CDE70:01C68335]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

Let's assume we have the following data model:

<if>
   <name>eth0</name>
   <opstate>up</opstate>
</if>

- if can be created/deleted max-access: all
- name must be created together with if max-access: all
- opstate is a read only variable that might be created automatically by the managed 
system max-access: read-only

If I want to create <if> can I create the read-only <opstate> object or do I have to rely 
  on the managed system to automaticaly create it ?

If I want to remove the <if> can I remove the read-only <opstate>? (I do not want to allow 
  removing <opstate> without removing <if>.)

What are the correct max-access setting ? (The question is the same both for Andy's and 
Sharon's solution.)

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 29 11:56:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fkk6N-0006Bq-Cn
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 11:56:19 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fkk6M-0003S3-3A
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 11:56:19 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fkk3B-000AX3-6n
	for netconf-data@psg.com; Mon, 29 May 2006 15:53:01 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.55] (helo=omr5.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fkk3A-000AWs-Ga
	for netconf@ops.ietf.org; Mon, 29 May 2006 15:53:00 +0000
Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68])
	by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k4TFqxV4018377
	for <netconf@ops.ietf.org>; Mon, 29 May 2006 11:52:59 -0400
Received: (qmail 6162 invoked by uid 78); 29 May 2006 15:52:59 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.68 with SMTP; 29 May 2006 15:52:59 -0000
Message-ID: <447B18D4.9030603@andybierman.com>
Date: Mon, 29 May 2006 08:52:52 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: max-access: access control model discussion
References: <446E131D.7080905@andybierman.com> <447B14F7.1000305@ericsson.com>
In-Reply-To: <447B14F7.1000305@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb

Balazs Lengyel wrote:
> Let's assume we have the following data model:
> 
> <if>
>   <name>eth0</name>
>   <opstate>up</opstate>
> </if>
> 
> - if can be created/deleted max-access: all
> - name must be created together with if max-access: all
> - opstate is a read only variable that might be created automatically by 
> the managed system max-access: read-only
> 
> If I want to create <if> can I create the read-only <opstate> object or 
> do I have to rely  on the managed system to automaticaly create it ?
> 
> If I want to remove the <if> can I remove the read-only <opstate>? (I do 
> not want to allow  removing <opstate> without removing <if>.)
> 
> What are the correct max-access setting ? (The question is the same both 
> for Andy's and Sharon's solution.)
> 

I will rewrite my original email to use existing MAX-ACCESS from SMIv2
instead of my extended MAX-ACCESS (based on well-known sub-states in MIBs),
In your example, read-create covers the case where read-write and read-only
data objects are instantiated by the agent, concurrently with the
objects instantiated by the NMS.

IMO, the actual netconf operations need to be explicitly supported
(notify, read, merge, replace, create, delete) with detailed text
explaining the mapping.

> Balazs

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 29 12:03:40 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FkkDU-0008Rb-7M
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 12:03:40 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FkkDS-0004RZ-Tx
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 12:03:40 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FkkAH-000B9d-LG
	for netconf-data@psg.com; Mon, 29 May 2006 16:00:21 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FkkAF-000B8I-2c
	for netconf@ops.ietf.org; Mon, 29 May 2006 16:00:19 +0000
Received: from mail.networksolutionsemail.com (ns-omr1.mgt.netsol.com [10.49.6.64])
	by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k4TG0I6Q015421
	for <netconf@ops.ietf.org>; Mon, 29 May 2006 12:00:18 -0400
Received: (qmail 9309 invoked by uid 78); 29 May 2006 16:00:18 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.64 with SMTP; 29 May 2006 16:00:18 -0000
Message-ID: <447B1A8C.2040908@andybierman.com>
Date: Mon, 29 May 2006 09:00:12 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: max-access: access control model discussion
References: <446E131D.7080905@andybierman.com> <447B0FE4.1010005@ericsson.com>
In-Reply-To: <447B0FE4.1010005@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Balazs Lengyel wrote:
> The draft proposes  a min-access part to describe conformance. I would 
> like to ask how much is the conformance statement used in SNMP? Do 
> management tools read it and handle MIBs according to it?

I pointed this out before.
MIN-ACCESS is compliance-specific, not data-model specific.
The entire module compliance and agent variance problem
needs to be thought out carefully.

Many WGs and vendors use MIN-ACCESS in MODULE-COMPLIANCE macros.
This is commonly done to define separate 'read-only' and 'read-write'
conformance statements for the same MIB module.
Some vendors also make use of AGENT-CAPABILITIES modules,
which describe agent-specific variations from the conformance
statements in the MIB modules.

> 
> Balazs

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 29 12:09:48 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FkkJQ-0002dl-9d
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 12:09:48 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FkkJJ-0004yO-OG
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 12:09:48 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FkkFs-000Bed-Cj
	for netconf-data@psg.com; Mon, 29 May 2006 16:06:08 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FkkFq-000BeL-UU
	for netconf@ops.ietf.org; Mon, 29 May 2006 16:06:07 +0000
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EB37A4F0001;
	Mon, 29 May 2006 18:06:05 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 29 May 2006 18:06:05 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 29 May 2006 18:06:05 +0200
Message-ID: <447B1BEC.8030808@ericsson.com>
Date: Mon, 29 May 2006 18:06:04 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: max-access: access control model discussion
References: <446E131D.7080905@andybierman.com> <447B14F7.1000305@ericsson.com> <447B18D4.9030603@andybierman.com>
In-Reply-To: <447B18D4.9030603@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 May 2006 16:06:05.0236 (UTC) FILETIME=[CA055740:01C68339]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955

I agree that a detailed mapping of max-access to operations is needed. The recent 
discussion about the operation parameter in edit-config also shows us that much of the 
complexity lies in understanding different access clauses on nested elements.

I would also say that mapping from the SMI-2 max-access clause is needed as we will be 
borrowing from the modeling work of SNMP.

I see the following main points about the two versions:
Sharon's max-access:
- It is assumed that the read,write,create,delete,execute rights are orthogonal in a sense 
so the netconf server needs to check only one of them for each operation not the complete set.

Andy's max-access:
_ It is assumed that the set of access possibilities is completely hierarchical so it is 
easier to use a smaller list then the 25 possible permutations in Sharon's list.

I believe both solutions could do the job.

Balazs



Andy Bierman wrote:
> Balazs Lengyel wrote:
>> Let's assume we have the following data model:
>>
>> <if>
>>   <name>eth0</name>
>>   <opstate>up</opstate>
>> </if>
>>
>> - if can be created/deleted max-access: all
>> - name must be created together with if max-access: all
>> - opstate is a read only variable that might be created automatically 
>> by the managed system max-access: read-only
>>
>> If I want to create <if> can I create the read-only <opstate> object 
>> or do I have to rely  on the managed system to automaticaly create it ?
>>
>> If I want to remove the <if> can I remove the read-only <opstate>? (I 
>> do not want to allow  removing <opstate> without removing <if>.)
>>
>> What are the correct max-access setting ? (The question is the same 
>> both for Andy's and Sharon's solution.)
>>
> 
> I will rewrite my original email to use existing MAX-ACCESS from SMIv2
> instead of my extended MAX-ACCESS (based on well-known sub-states in MIBs),
> In your example, read-create covers the case where read-write and read-only
> data objects are instantiated by the agent, concurrently with the
> objects instantiated by the NMS.
> 
> IMO, the actual netconf operations need to be explicitly supported
> (notify, read, merge, replace, create, delete) with detailed text
> explaining the mapping.
> 
>> Balazs
> 
> Andy

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 29 12:31:24 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FkkeK-00037f-Jx
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 12:31:24 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FkjR5-0005go-Ti
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 11:13:39 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FkjR3-0006KG-UZ
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 11:13:39 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FkjN6-0007a7-AU
	for netconf-data@psg.com; Mon, 29 May 2006 15:09:32 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FkjN5-0007Zq-Ko
	for netconf@ops.ietf.org; Mon, 29 May 2006 15:09:31 +0000
Received: from mail.networksolutionsemail.com (ns-omr1.mgt.netsol.com [10.49.6.64])
	by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k4TF9Vk8013789
	for <netconf@ops.ietf.org>; Mon, 29 May 2006 11:09:31 -0400
Received: (qmail 20911 invoked by uid 78); 29 May 2006 15:09:30 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.64 with SMTP; 29 May 2006 15:09:30 -0000
Message-ID: <447B0EA4.1000806@andybierman.com>
Date: Mon, 29 May 2006 08:09:24 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: Martin Bjorklund <mbj@tail-f.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: subtree filter spec vs. implementation
References: <200605291247.k4TClbO4090168@idle.juniper.net>
In-Reply-To: <200605291247.k4TClbO4090168@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
X-Spam-Score: -2.3 (--)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32

Phil Shafer wrote:
> Andy Bierman writes:
>> 1) If <users> is empty:
>> 2) If <users> is not empty, but entry for 'fred' does not exist:
> 
> Both of these cases return an empty <configuration> element.
> Filtering on something that isn't there gets you nothing.
> 
>     <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/8.0I0/junos">
>       <data>
>         <configuration>
>         </configuration>

Why are you returning the <configuration> element in this reply?
 From the netconf POV, it seems the <filter> element in the
request maps to the <data> element in the reply.  If a 'FALSE' filter
adds nothing to the output, it seems like the <data> element should be empty.


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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 29 13:59:33 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fkm1d-0000CN-DR
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 13:59:33 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FkjwN-00017Y-0b
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 11:45:59 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FkjVB-0006WH-IX
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 11:18:00 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FkjSC-0007x9-8Z
	for netconf-data@psg.com; Mon, 29 May 2006 15:14:48 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FkjSA-0007wo-SB
	for netconf@ops.ietf.org; Mon, 29 May 2006 15:14:47 +0000
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B42D04F0002
	for <netconf@ops.ietf.org>; Mon, 29 May 2006 17:14:45 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 29 May 2006 17:14:45 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 29 May 2006 17:14:44 +0200
Message-ID: <447B0FE4.1010005@ericsson.com>
Date: Mon, 29 May 2006 17:14:44 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: max-access: access control model discussion
References: <446E131D.7080905@andybierman.com>
In-Reply-To: <446E131D.7080905@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 May 2006 15:14:44.0806 (UTC) FILETIME=[9DF10660:01C68332]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de

The draft proposes  a min-access part to describe conformance. I would like to ask how 
much is the conformance statement used in SNMP? Do management tools read it and handle 
MIBs according to it?

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 29 14:12:35 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FkmEF-0003Go-Kh
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 14:12:35 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FkmEF-0000UT-J4
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 14:12:35 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1Fkm1e-0000xA-Gm
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 13:59:36 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fklwv-000Ibd-Ff
	for netconf-data@psg.com; Mon, 29 May 2006 17:54:41 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fklwu-000IbP-EV
	for netconf@ops.ietf.org; Mon, 29 May 2006 17:54:40 +0000
Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65])
	by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k4THsdZG026374
	for <netconf@ops.ietf.org>; Mon, 29 May 2006 13:54:39 -0400
Received: (qmail 5496 invoked by uid 78); 29 May 2006 17:54:39 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 29 May 2006 17:54:39 -0000
Message-ID: <447B3558.80808@andybierman.com>
Date: Mon, 29 May 2006 10:54:32 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: max-access: access control model discussion
References: <446E131D.7080905@andybierman.com> <447B14F7.1000305@ericsson.com> <447B18D4.9030603@andybierman.com> <447B1BEC.8030808@ericsson.com>
In-Reply-To: <447B1BEC.8030808@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.3 (--)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8

Balazs Lengyel wrote:
> I agree that a detailed mapping of max-access to operations is needed. 
> The recent discussion about the operation parameter in edit-config also 
> shows us that much of the complexity lies in understanding different 
> access clauses on nested elements.

This problem has been studied before in the SMIng WG.
Nested MAX-ACCESS is not purely hierarchical.

This is one area where containers really help.
Consider nested containers in dynamic 'rows'.
The NMS creates the parent row, and the agent
creates a read-only container in that row.
After this operation succeeds, the NMS has read-create
access to create entries in that nested container.


> 
> I would also say that mapping from the SMI-2 max-access clause is needed 
> as we will be borrowing from the modeling work of SNMP.
> 
> I see the following main points about the two versions:
> Sharon's max-access:
> - It is assumed that the read,write,create,delete,execute rights are 
> orthogonal in a sense so the netconf server needs to check only one of 
> them for each operation not the complete set.

This is not true.
Consider the 'replace' operation carefully.
It can be any or all of "create, write, delete",
in the same PDU.


> 
> Andy's max-access:
> _ It is assumed that the set of access possibilities is completely 
> hierarchical so it is easier to use a smaller list then the 25 possible 
> permutations in Sharon's list.
> 
> I believe both solutions could do the job.
> 
> Balazs
> 


Andy


> 
> 
> Andy Bierman wrote:
>> Balazs Lengyel wrote:
>>> Let's assume we have the following data model:
>>>
>>> <if>
>>>   <name>eth0</name>
>>>   <opstate>up</opstate>
>>> </if>
>>>
>>> - if can be created/deleted max-access: all
>>> - name must be created together with if max-access: all
>>> - opstate is a read only variable that might be created automatically 
>>> by the managed system max-access: read-only
>>>
>>> If I want to create <if> can I create the read-only <opstate> object 
>>> or do I have to rely  on the managed system to automaticaly create it ?
>>>
>>> If I want to remove the <if> can I remove the read-only <opstate>? (I 
>>> do not want to allow  removing <opstate> without removing <if>.)
>>>
>>> What are the correct max-access setting ? (The question is the same 
>>> both for Andy's and Sharon's solution.)
>>>
>>
>> I will rewrite my original email to use existing MAX-ACCESS from SMIv2
>> instead of my extended MAX-ACCESS (based on well-known sub-states in 
>> MIBs),
>> In your example, read-create covers the case where read-write and 
>> read-only
>> data objects are instantiated by the agent, concurrently with the
>> objects instantiated by the NMS.
>>
>> IMO, the actual netconf operations need to be explicitly supported
>> (notify, read, merge, replace, create, delete) with detailed text
>> explaining the mapping.
>>
>>> Balazs
>>
>> 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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 29 14:34:53 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FkmZp-0003aV-0A
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 14:34:53 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FkmZj-0002MS-NO
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 14:34:52 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FkmWH-000L8N-OA
	for netconf-data@psg.com; Mon, 29 May 2006 18:31:13 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [83.241.162.138] (helo=mail.tail-f.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mbj@tail-f.com>)
	id 1FkmWG-000L8A-Os
	for netconf@ops.ietf.org; Mon, 29 May 2006 18:31:12 +0000
Received: from localhost (c213-100-166-87.swipnet.se [213.100.166.87])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id 5B8EA43;
	Mon, 29 May 2006 20:31:11 +0200 (CEST)
Date: Mon, 29 May 2006 20:31:00 +0200 (CEST)
Message-Id: <20060529.203100.82193993.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: phil@juniper.net, netconf@ops.ietf.org
Subject: Re: subtree filter spec vs. implementation
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <447B01C8.8060303@andybierman.com>
References: <200605291247.k4TClbO4090168@idle.juniper.net>
	<447B01C8.8060303@andybierman.com>
X-Mailer: Mew version 2.2rc2-mbj2 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

Andy Bierman <ietf@andybierman.com> wrote:
> > This is bad news.  Can we issue an errata for a spec?
> 
> I hope so.
> We need to agree on the text.
> I searched some old drafts and could not find my
> original sentence regarding removal of dead-end sub-trees.
> 
> FWIW, I think it is about the same amount of work
> to implement subtree filtering either way.

This is very subjective of course, but I think the current spec is
easier to implement.  The reason is that when a containment node is
found in the filter, the code can directly write the node to the
output stream if it exists.  With the proposed change, the code would
have to buffer more.  With the current spec, max one level of
buffering is needed (for content match nodes).  No rocket science of
course.


/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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Mon May 29 15:11:22 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fkn98-0008Bv-6n
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 15:11:22 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fkn96-0006qL-Sj
	for netconf-archive@lists.ietf.org; Mon, 29 May 2006 15:11:22 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fkn5b-000NUz-KS
	for netconf-data@psg.com; Mon, 29 May 2006 19:07:43 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1Fkn5K-000NUD-E3
	for netconf@ops.ietf.org; Mon, 29 May 2006 19:07:27 +0000
Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65])
	by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k4TJ7O47003181
	for <netconf@ops.ietf.org>; Mon, 29 May 2006 15:07:24 -0400
Received: (qmail 32328 invoked by uid 78); 29 May 2006 19:07:24 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 29 May 2006 19:07:24 -0000
Message-ID: <447B4666.5040800@andybierman.com>
Date: Mon, 29 May 2006 12:07:18 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC: phil@juniper.net, netconf@ops.ietf.org
Subject: Re: subtree filter spec vs. implementation
References: <200605291247.k4TClbO4090168@idle.juniper.net>	<447B01C8.8060303@andybierman.com> <20060529.203100.82193993.mbj@tail-f.com>
In-Reply-To: <20060529.203100.82193993.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>>> This is bad news.  Can we issue an errata for a spec?
>> I hope so.
>> We need to agree on the text.
>> I searched some old drafts and could not find my
>> original sentence regarding removal of dead-end sub-trees.
>>
>> FWIW, I think it is about the same amount of work
>> to implement subtree filtering either way.
> 
> This is very subjective of course, but I think the current spec is
> easier to implement.  The reason is that when a containment node is
> found in the filter, the code can directly write the node to the
> output stream if it exists.  With the proposed change, the code would
> have to buffer more.  With the current spec, max one level of
> buffering is needed (for content match nodes).  No rocket science of
> course.

Implementation details will vary a lot here,
so it's hard to compare apples to apples.

It could be the same amount of data saved,
but you may have to go through the filter tree
twice -- once to prune it, and then again
to output the matching nodes (the ones still there
after the pruning).

> 
> 
> /martin

Andy

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 30 07:44:06 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fl2dq-0005Li-2R
	for netconf-archive@lists.ietf.org; Tue, 30 May 2006 07:44:06 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fl2de-0000oV-Kf
	for netconf-archive@lists.ietf.org; Tue, 30 May 2006 07:44:06 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fl2XM-0007H7-Ed
	for netconf-data@psg.com; Tue, 30 May 2006 11:37:24 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1Fl2XL-0007Gw-6K
	for netconf@ops.ietf.org; Tue, 30 May 2006 11:37:23 +0000
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 236E14F0002;
	Tue, 30 May 2006 13:37:22 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 30 May 2006 13:37:21 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 30 May 2006 13:37:21 +0200
Message-ID: <447C2E71.5050901@ericsson.com>
Date: Tue, 30 May 2006 13:37:21 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: subtree filter spec vs. implementation
References: <200605291247.k4TClbO4090168@idle.juniper.net> <447B01C8.8060303@andybierman.com>
In-Reply-To: <447B01C8.8060303@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 May 2006 11:37:21.0265 (UTC) FILETIME=[69CC5E10:01C683DD]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370

Hello Andy,
Do you have a list of items that you want to add? The following come to my mind:
- subtree filtering
- how nested operation parameters work in edit-config
- replacement of the whole subtree
Balazs

Andy Bierman wrote:
>> This is bad news.  Can we issue an errata for a spec?
> 
> I hope so.
> We need to agree on the text.

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 30 13:38:37 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fl8Av-0000UH-OA
	for netconf-archive@lists.ietf.org; Tue, 30 May 2006 13:38:37 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fl8Ap-0002iO-CJ
	for netconf-archive@lists.ietf.org; Tue, 30 May 2006 13:38:37 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fl84c-0009Nm-DG
	for netconf-data@psg.com; Tue, 30 May 2006 17:32:06 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1
Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <nwnetworks@dial.pipex.com>)
	id 1Fl84b-0009NZ-2o
	for netconf@ops.ietf.org; Tue, 30 May 2006 17:32:05 +0000
Received: from pc6 (1Cust154.tnt28.lnd4.gbr.da.uu.net [62.188.156.154])
	by galaxy.systems.pipex.net (Postfix) with SMTP id 713FBE000096;
	Tue, 30 May 2006 18:31:54 +0100 (BST)
Message-ID: <055101c68406$1a62f180$0601a8c0@pc6>
Reply-To: "Tom Petch" <nwnetworks@dial.pipex.com>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: "Andy Bierman" <ietf@andybierman.com>,
	"Netconf Data Model Discussion" <netconfmodel@lists.nortel.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>,
	"Netconf Data Model Discussion" <netconfmodel@lists.nortel.com>
References: <713043CE8B8E1348AF3C546DBE02C1B4089DFEAE@zcarhxm2.corp.nortel.com> <LYRIS-39268-603484-2006.05.23-16.05.12--nwnetworks#dial.pipex.com@ztcfd0k3.ca.nortel.com>
Subject: Re: max-access: access control model discussion
Date: Tue, 30 May 2006 17:38:20 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a

<inline>

Tom Petch

----- Original Message -----
From: "Andy Bierman" <ietf@andybierman.com>
To: "Netconf Data Model Discussion" <netconfmodel@lists.nortel.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>; "Netconf Data Model Discussion"
<netconfmodel@lists.nortel.com>
Sent: Tuesday, May 23, 2006 10:00 PM
Subject: Re: max-access: access control model discussion


> Sharon Chisholm wrote:
> >
> > This seems much more complicated then what is in the draft. I prefer the
> > approach of defining a list of values rather then enumerating all the
> > combinations and permutations of the items in the list as unique values.
> >
>
> What is in the draft is rather under-specified.
>
> Forget my "extended MAX-ACCESS".  That was a mistake.
> Think of the MAX-ACCESS clause exactly as defined in SMIv2 instead.
>
> The real issue is whether the application of SMIv2 MIB modules
> for use in the NETCONF protocol is of any interest whatsoever.
> If so, then a mapping of the MAX-ACCESS clause to
> the NETCONF protocol operations is required.
> The operations 'notify' and 'read' are easy.
> The other operations (merge, replace, create, delete)
> are not as easy.  There are plenty of interesting
> corner-cases where 'merge' and 'replace' do not behave
> the same wrt/ access control (or function).
>
> IMO, it would be better to use 1 MAX-ACCESS string
> per clause, and use the enumerated values from SMIv2 MAX-ACCESS.
> Normative text describing the mapping to the NETCONF protocol
> is also needed. This small amount of reuse would be a step in the
> right direction.
>
Agree strongly.  Of course we can come up with something more sophisticated,
perhaps we can produce something noticeably better, but there is much to be said
in engineering for the reuse of familiar building bricks that have stood the
test of time, and have not, AFAIK, been the subject of significant criticism.
It is not, for me, a question of wanting to reuse MIB modules written in SMIv2,
but having a good concept that is worth perpetuating.

This logic equally says if there is a better model elsewhere, perhaps in the
libraries of ITU-T, then I would support the use of that but, AFAIK, there is
not.

Tom Petch

<snip>


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 30 15:07:50 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fl9ZG-0007gY-Qm
	for netconf-archive@lists.ietf.org; Tue, 30 May 2006 15:07:50 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fl9ZD-00017o-ET
	for netconf-archive@lists.ietf.org; Tue, 30 May 2006 15:07:50 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1Fl9RG-000FDO-1a
	for netconf-data@psg.com; Tue, 30 May 2006 18:59:34 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [209.128.82.1] (helo=shell4.bayarea.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <dperkins@dsperkins.com>)
	id 1Fl9RF-000FDD-GJ
	for netconf@ops.ietf.org; Tue, 30 May 2006 18:59:33 +0000
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k4UIxLRa019513;
	Tue, 30 May 2006 11:59:22 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k4UIxItg019497;
	Tue, 30 May 2006 11:59:21 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Tue, 30 May 2006 11:59:18 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: max-access: access control model discussion
In-Reply-To: <447B0FE4.1010005@ericsson.com>
Message-ID: <Pine.LNX.4.10.10605301152070.21537-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa

HI,

So it looks like you have also misinterpreted what
"MODULE-COMPLIANCE" and "AGENT-CAPABILITIES" are to
be used for.

A MODULE-COMPLIANCE is a "requirements specification".
It can be used in standards documents to say in
a formal way what must be implemented by an SNMP agent
to conform to the standard. It can also be used in
a Request for Proposal to indicate what you want.
And finally, it can be used by management applications
to say what must be implemented by an SNMP agent so
that the management app can work.

A AGENT-CAPABILITIES is a formal specification of
what is implemented by an SNMP agent. It doesn't
indicate what instances are presently in existance.

Are MODULE-COMPLIANCE and AGENT-CAPABILITIES used?
This is an long running question, with a very
spotty answer. Part of it's problem is with
the definition of what "implemented by the SNMP
agent" means.

Regards,
/david t. perkins

On Mon, 29 May 2006, Balazs Lengyel wrote:
> The draft proposes  a min-access part to describe conformance. I would like to ask how 
> much is the conformance statement used in SNMP? Do management tools read it and handle 
> MIBs according to it?
> 
> 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: <http://ops.ietf.org/lists/netconf/>
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 30 16:15:04 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FlAcK-0006e0-Ia
	for netconf-archive@lists.ietf.org; Tue, 30 May 2006 16:15:04 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FlAcJ-0000BX-4a
	for netconf-archive@lists.ietf.org; Tue, 30 May 2006 16:15:04 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FlAXR-000KSn-NC
	for netconf-data@psg.com; Tue, 30 May 2006 20:10:01 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FlAXQ-000KS2-9I
	for netconf@ops.ietf.org; Tue, 30 May 2006 20:10:00 +0000
Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65])
	by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k4UGIofm029369
	for <netconf@ops.ietf.org>; Tue, 30 May 2006 12:18:58 -0400
Received: (qmail 7157 invoked by uid 78); 30 May 2006 16:17:24 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 30 May 2006 16:17:24 -0000
Message-ID: <447C7008.4050903@andybierman.com>
Date: Tue, 30 May 2006 09:17:12 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Netconf WG IETF 66 and Montreal Interim Meeting Agenda (draft)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f

Hi,

Here is the first draft of the interim agenda for comment:

---------------

The NETCONF WG will meet at IETF #66, and the Montreal interim meeting
following, to work on NETCONF Notifications work item. 

 - Interim Meeting Location
   IETF Headquarter Hotel: Delta Centre-Ville
   777 University Street
   Montreal, Quebec, Canada, H3C 3Z7
   Hotel WEB site:
   http://www.deltahotels.com/hotels/hotels.php?hotelId=35

 - Interim Meeting Times
   Friday, July 14, 2006 (1:30 PM - 6:00 PM)
   Saturday, July 15, 2006 (9:00 AM - 6:00 PM)

 - Required Reading
   NETCONF Event Notifications
   
http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-01.txt


The following is a proposed issues list.  The discussion sequence at the
meetings will generally follow this list, but issues that are inter-related
may affect the order.  The official WG meeting on July 14, 9:00 - 11:30 AM
will be used to discuss and prioritize functional requirements.


 - Functional Requirements
   - determine WG consensus on need and priority of Juergen's list
     http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications

 - Architecture

   - role of notifications within netconf
   - relationship to syslog and snmp notifications
   - scaling issues
   - security issues (session vs. signed msg, etc.)
   - standard RPC methods vs. new RPC methods
   - agent resource vs. NMS resource issues

 - Use within Sessions

   - endless RPC
   - mixed-mode (rpc operations and notifications)
   - single vs. multiple subscriptions within a single session
  

 - Transport Specific Support

   - use of channels (ssh, beep, what about soap?)
   - callhome support for agent initiated sessions

 - Agent Notification Configuration and Control Mechanism

   - config-data vs. subscription-data
   - RPCs used to configure and control agent notification generation

 - Notification Event Classes

   - WG consensus on specific list
   - Guidelines for selecting classifications

 - Notification Filtering
 
   - Configuration mechanism(s)
   - Agent processing model

 - Notification Header Content

   - Syntax and semantics of data included in all notifications

 - Standard Notification Content

   - WG consensus on 0 or more fully-specified standard notifications
   - Full syntax and semantics of each standard notification

 - Read-only (monitoring) data for agent notification activity

 - Access Control Issues

 - Data Model and XSD Issues

   - Data model design
   - XSD correctness
   - Need for 'min-access' and 'max-access'

 - Documentation Issues

   - Terminology
   - Inclusion of non-normative text
   - Document section order
   - Document clarity
   - Choice of examples
   - Example correctness (need to validate against the XSD)




--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Tue May 30 17:00:28 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FlBKG-0004Sz-Au
	for netconf-archive@lists.ietf.org; Tue, 30 May 2006 17:00:28 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FlAI2-0007af-AL
	for netconf-archive@lists.ietf.org; Tue, 30 May 2006 15:54:06 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FlAAl-0001TY-HG
	for netconf-archive@lists.ietf.org; Tue, 30 May 2006 15:46:40 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FlA4z-000I5E-Gz
	for netconf-data@psg.com; Tue, 30 May 2006 19:40:37 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.56] (helo=omr6.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FlA4x-000I4h-Ka
	for netconf@ops.ietf.org; Tue, 30 May 2006 19:40:36 +0000
Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69])
	by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k4UJeYId003479
	for <netconf@ops.ietf.org>; Tue, 30 May 2006 15:40:34 -0400
Received: (qmail 16408 invoked by uid 78); 30 May 2006 19:40:21 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.69 with SMTP; 30 May 2006 19:40:21 -0000
Message-ID: <447C9F9E.7090208@andybierman.com>
Date: Tue, 30 May 2006 12:40:14 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Netconf WG IETF 66 and Montreal Interim Meeting Agenda (draft)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.3 (--)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6

Hi,

Here is the first draft of the interim agenda for comment:
[resend]

---------------

The NETCONF WG will meet at IETF #66, and the Montreal interim meeting
following, to work on NETCONF Notifications work item.

- Interim Meeting Location
   IETF Headquarter Hotel: Delta Centre-Ville
   777 University Street
   Montreal, Quebec, Canada, H3C 3Z7
   Hotel WEB site:
   http://www.deltahotels.com/hotels/hotels.php?hotelId=35

- Interim Meeting Times
   Friday, July 14, 2006 (1:30 PM - 6:00 PM)
   Saturday, July 15, 2006 (9:00 AM - 6:00 PM)

- Required Reading
   NETCONF Event Notifications

http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-01.txt


The following is a proposed issues list.  The discussion sequence at the
meetings will generally follow this list, but issues that are inter-related
may affect the order.  The official WG meeting on July 14, 9:00 - 11:30 AM
will be used to discuss and prioritize functional requirements.


- Functional Requirements
   - determine WG consensus on need and priority of Juergen's list
     http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications

- Architecture

   - role of notifications within netconf
   - relationship to syslog and snmp notifications
   - scaling issues
   - security issues (session vs. signed msg, etc.)
   - standard RPC methods vs. new RPC methods
   - agent resource vs. NMS resource issues

- Use within Sessions

   - endless RPC
   - mixed-mode (rpc operations and notifications)
   - single vs. multiple subscriptions within a single session


- Transport Specific Support

   - use of channels (ssh, beep, what about soap?)
   - callhome support for agent initiated sessions

- Agent Notification Configuration and Control Mechanism

   - config-data vs. subscription-data
   - RPCs used to configure and control agent notification generation

- Notification Event Classes

   - WG consensus on specific list
   - Guidelines for selecting classifications

- Notification Filtering

   - Configuration mechanism(s)
   - Agent processing model

- Notification Header Content

   - Syntax and semantics of data included in all notifications

- Standard Notification Content

   - WG consensus on 0 or more fully-specified standard notifications
   - Full syntax and semantics of each standard notification

- Read-only (monitoring) data for agent notification activity

- Access Control Issues

- Data Model and XSD Issues

   - Data model design
   - XSD correctness
   - Need for 'min-access' and 'max-access'

- Documentation Issues

   - Terminology
   - Inclusion of non-normative text
   - Document section order
   - Document clarity
   - Choice of examples
   - Example correctness (need to validate against the XSD)





--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 31 01:45:16 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FlJW7-0004UV-V3
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 01:45:15 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FlJTD-0003zC-B0
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 01:42:20 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FlJMY-000B40-EQ
	for netconf-data@psg.com; Wed, 31 May 2006 05:35:22 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1FlJMX-000B3k-E8
	for netconf@ops.ietf.org; Wed, 31 May 2006 05:35:21 +0000
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4V5WoIG026944
	for <netconf@ops.ietf.org>; Wed, 31 May 2006 01:32:51 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C68473.FF98BE58"
Subject: FW: I-D ACTION:draft-vandyke-mscml-08.txt 
Date: Wed, 31 May 2006 08:35:17 +0300
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A953811@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-vandyke-mscml-08.txt 
Thread-Index: AcaEO9NXftzDDp9tRGK8Bw5f4E+dPgAN+5sQ
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: <netconfmodel@lists.nortel.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3

This is a multi-part message in MIME format.

------_=_NextPart_001_01C68473.FF98BE58
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20
FYI, an individual submission in the conferencing and Interactive Voice
Response (IVR) configuration domain.=20

Dan


=20

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20
Sent: Wednesday, May 31, 2006 1:50 AM
To: i-d-announce@ietf.org
Subject: I-D ACTION:draft-vandyke-mscml-08.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Media Server Control Markup Language (MSCML)
and Protocol
	Author(s)	: J. Van Dyke, et al.
	Filename	: draft-vandyke-mscml-08.txt
	Pages		: 74
	Date		: 2006-5-30
=09
Media Server Control Markup Language (MSCML) is a markup language
   used in conjunction with SIP to provide advanced conferencing and
   interactive voice response (IVR) functions.  MSCML presents an
   application-level control model, as opposed to device-level control
   models.  One use of this protocol is for communications between a
   conference focus and mixer in the IETF SIP Conferencing Framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-vandyke-mscml-08.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of
the message. =20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
	"get draft-vandyke-mscml-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-vandyke-mscml-08.txt".
=09
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


------_=_NextPart_001_01C68473.FF98BE58
Content-Type: application/octet-stream;
	name="ATT393423.TXT"
Content-Transfer-Encoding: base64
Content-Description: ATT393423.TXT
Content-Disposition: attachment;
	filename="ATT393423.TXT"

Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl
cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0
L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNi01LTMwMTYyODA4LkktREBpZXRmLm9yZz4NCg0KRU5D
T0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXZhbmR5a2UtbXNjbWwtMDgu
dHh0DQo=

------_=_NextPart_001_01C68473.FF98BE58
Content-Type: application/octet-stream;
	name="draft-vandyke-mscml-08.URL"
Content-Transfer-Encoding: base64
Content-Description: draft-vandyke-mscml-08.URL
Content-Disposition: attachment;
	filename="draft-vandyke-mscml-08.URL"

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC12YW5keWtlLW1zY21sLTA4LnR4dA0K

------_=_NextPart_001_01C68473.FF98BE58
Content-Type: text/plain;
	name="ATT393424.txt"
Content-Transfer-Encoding: base64
Content-Description: ATT393424.txt
Content-Disposition: attachment;
	filename="ATT393424.txt"

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v
dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo=

------_=_NextPart_001_01C68473.FF98BE58--

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 31 09:10:37 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FlQT7-0000lP-KV
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 09:10:37 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FlQT6-0002vj-Aw
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 09:10:37 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FlQL6-0003wm-DJ
	for netconf-data@psg.com; Wed, 31 May 2006 13:02:20 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 
	autolearn=unavailable version=3.1.1
Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from <dromasca@avaya.com>)
	id 1FlQL5-0003wN-3G; Wed, 31 May 2006 13:02:19 +0000
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4VCxmTF030940;
	Wed, 31 May 2006 08:59:49 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Creation of nettest mailing list
Date: Wed, 31 May 2006 16:02:15 +0300
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A953CBC@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Creation of nettest mailing list
Thread-Index: AcaEsnCI3u8k9DI6Rtmjemzq9GgXpA==
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: <ietf@ietf.org>, <wgchairs@ietf.org>,
        "Ops-Nm \(E-mail\)" <ops-nm@ops.ietf.org>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>, <bmwg@ietf.org>
Cc: <nettest@ietf.org>, "IESG" <iesg@ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa


This is an announcement for the creation of the NETTEST mail list

 nettest@ietf.org

General information about the mailing list is at:

  https://www1.ietf.org/mailman/listinfo/nettest

Craig Brown (crbrown@cisco.com) is the administrator of the list.=20

The purpose of the list is to open the discussions for proposing a new
specification for the development of a protocol for the management of
network test devices in the areas of data, voice, video, security, and
storage.=20

The end goal is to submit an I-D and discuss a request for a BOF.=20

In preparation we will discuss:

. The NETTEST charter - "the development a protocol for the management
of network test devices in the areas of data, voice, video, security,
and storage"

. The goals of NETTEST

. Some of the discussions to develop the I-D will include:

	. Experiences already learnt from the current API specifications
	. Review existing standards to understand what fits
	. Outline the NETTEST protocol layer that the technologies will
use
	. The method of managing data structures

The expectation is to not come to a final decision of all technology
specifics prior to the BoF, but to instead have detailed explanations
and group understanding of the NETTEST objectives and technology
overview.

=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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 31 10:33:07 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FlRkx-0000vH-Uk
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 10:33:07 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FlRkx-0000Yc-RK
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 10:33:07 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FlRkr-00007R-Al
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 10:33:07 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FlRdA-000CIN-Gl
	for netconf-data@psg.com; Wed, 31 May 2006 14:25:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FlRd8-000CHM-Cw
	for netconf@ops.ietf.org; Wed, 31 May 2006 14:25:02 +0000
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4DD504F0002;
	Wed, 31 May 2006 16:25:01 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 31 May 2006 16:24:59 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 31 May 2006 16:24:59 +0200
Message-ID: <447DA73A.8040900@ericsson.com>
Date: Wed, 31 May 2006 16:24:58 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Netconf WG IETF 66 and Montreal Interim Meeting Agenda (draft)
References: <447C9F9E.7090208@andybierman.com>
In-Reply-To: <447C9F9E.7090208@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 31 May 2006 14:24:59.0154 (UTC) FILETIME=[FF2E2F20:01C684BD]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b

I thought (I hoped) that Sharon aims to update the draft before the meeting.
Balazs

Andy Bierman wrote:
> Hi,
> 
> Here is the first draft of the interim agenda for comment:
> [resend]
> 
> ---------------
> 
> The NETCONF WG will meet at IETF #66, and the Montreal interim meeting
> following, to work on NETCONF Notifications work item.
> 
> - Interim Meeting Location
>   IETF Headquarter Hotel: Delta Centre-Ville
>   777 University Street
>   Montreal, Quebec, Canada, H3C 3Z7
>   Hotel WEB site:
>   http://www.deltahotels.com/hotels/hotels.php?hotelId=35
> 
> - Interim Meeting Times
>   Friday, July 14, 2006 (1:30 PM - 6:00 PM)
>   Saturday, July 15, 2006 (9:00 AM - 6:00 PM)
> 
> - Required Reading
>   NETCONF Event Notifications
> 
> http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-01.txt
> 
> 
> The following is a proposed issues list.  The discussion sequence at the
> meetings will generally follow this list, but issues that are inter-related
> may affect the order.  The official WG meeting on July 14, 9:00 - 11:30 AM
> will be used to discuss and prioritize functional requirements.
> 
> 
> - Functional Requirements
>   - determine WG consensus on need and priority of Juergen's list
>     http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications
> 
> - Architecture
> 
>   - role of notifications within netconf
>   - relationship to syslog and snmp notifications
>   - scaling issues
>   - security issues (session vs. signed msg, etc.)
>   - standard RPC methods vs. new RPC methods
>   - agent resource vs. NMS resource issues
> 
> - Use within Sessions
> 
>   - endless RPC
>   - mixed-mode (rpc operations and notifications)
>   - single vs. multiple subscriptions within a single session
> 
> 
> - Transport Specific Support
> 
>   - use of channels (ssh, beep, what about soap?)
>   - callhome support for agent initiated sessions
> 
> - Agent Notification Configuration and Control Mechanism
> 
>   - config-data vs. subscription-data
>   - RPCs used to configure and control agent notification generation
> 
> - Notification Event Classes
> 
>   - WG consensus on specific list
>   - Guidelines for selecting classifications
> 
> - Notification Filtering
> 
>   - Configuration mechanism(s)
>   - Agent processing model
> 
> - Notification Header Content
> 
>   - Syntax and semantics of data included in all notifications
> 
> - Standard Notification Content
> 
>   - WG consensus on 0 or more fully-specified standard notifications
>   - Full syntax and semantics of each standard notification
> 
> - Read-only (monitoring) data for agent notification activity
> 
> - Access Control Issues
> 
> - Data Model and XSD Issues
> 
>   - Data model design
>   - XSD correctness
>   - Need for 'min-access' and 'max-access'
> 
> - Documentation Issues
> 
>   - Terminology
>   - Inclusion of non-normative text
>   - Document section order
>   - Document clarity
>   - Choice of examples
>   - Example correctness (need to validate against the XSD)
> 
> 
> 
> 
> 
> -- 
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 31 11:06:32 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FlSAw-0004RB-Ib
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 10:59:58 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FlRwV-0001sq-Dn
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 10:45:07 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FlRnb-000DCa-5s
	for netconf-data@psg.com; Wed, 31 May 2006 14:35:51 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.53] (helo=omr3.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FlRnZ-000DCL-T0
	for netconf@ops.ietf.org; Wed, 31 May 2006 14:35:50 +0000
Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66])
	by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k4VEZnRw008446
	for <netconf@ops.ietf.org>; Wed, 31 May 2006 10:35:49 -0400
Received: (qmail 5240 invoked by uid 78); 31 May 2006 14:35:48 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.66 with SMTP; 31 May 2006 14:35:48 -0000
Message-ID: <447DA9BE.3020700@andybierman.com>
Date: Wed, 31 May 2006 07:35:42 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Netconf WG IETF 66 and Montreal Interim Meeting Agenda (draft)
References: <447C9F9E.7090208@andybierman.com> <447DA73A.8040900@ericsson.com>
In-Reply-To: <447DA73A.8040900@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c

Balazs Lengyel wrote:
> I thought (I hoped) that Sharon aims to update the draft before the 
> meeting.

Good idea.
We will try to reach consensus on some issues
so there are edits to make.  The authors can
always do bug-fixes as they find them as well.


> Balazs

Andy


> 
> Andy Bierman wrote:
>> Hi,
>>
>> Here is the first draft of the interim agenda for comment:
>> [resend]
>>
>> ---------------
>>
>> The NETCONF WG will meet at IETF #66, and the Montreal interim meeting
>> following, to work on NETCONF Notifications work item.
>>
>> - Interim Meeting Location
>>   IETF Headquarter Hotel: Delta Centre-Ville
>>   777 University Street
>>   Montreal, Quebec, Canada, H3C 3Z7
>>   Hotel WEB site:
>>   http://www.deltahotels.com/hotels/hotels.php?hotelId=35
>>
>> - Interim Meeting Times
>>   Friday, July 14, 2006 (1:30 PM - 6:00 PM)
>>   Saturday, July 15, 2006 (9:00 AM - 6:00 PM)
>>
>> - Required Reading
>>   NETCONF Event Notifications
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-01.txt 
>>
>>
>>
>> The following is a proposed issues list.  The discussion sequence at the
>> meetings will generally follow this list, but issues that are 
>> inter-related
>> may affect the order.  The official WG meeting on July 14, 9:00 - 
>> 11:30 AM
>> will be used to discuss and prioritize functional requirements.
>>
>>
>> - Functional Requirements
>>   - determine WG consensus on need and priority of Juergen's list
>>     http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications
>>
>> - Architecture
>>
>>   - role of notifications within netconf
>>   - relationship to syslog and snmp notifications
>>   - scaling issues
>>   - security issues (session vs. signed msg, etc.)
>>   - standard RPC methods vs. new RPC methods
>>   - agent resource vs. NMS resource issues
>>
>> - Use within Sessions
>>
>>   - endless RPC
>>   - mixed-mode (rpc operations and notifications)
>>   - single vs. multiple subscriptions within a single session
>>
>>
>> - Transport Specific Support
>>
>>   - use of channels (ssh, beep, what about soap?)
>>   - callhome support for agent initiated sessions
>>
>> - Agent Notification Configuration and Control Mechanism
>>
>>   - config-data vs. subscription-data
>>   - RPCs used to configure and control agent notification generation
>>
>> - Notification Event Classes
>>
>>   - WG consensus on specific list
>>   - Guidelines for selecting classifications
>>
>> - Notification Filtering
>>
>>   - Configuration mechanism(s)
>>   - Agent processing model
>>
>> - Notification Header Content
>>
>>   - Syntax and semantics of data included in all notifications
>>
>> - Standard Notification Content
>>
>>   - WG consensus on 0 or more fully-specified standard notifications
>>   - Full syntax and semantics of each standard notification
>>
>> - Read-only (monitoring) data for agent notification activity
>>
>> - Access Control Issues
>>
>> - Data Model and XSD Issues
>>
>>   - Data model design
>>   - XSD correctness
>>   - Need for 'min-access' and 'max-access'
>>
>> - Documentation Issues
>>
>>   - Terminology
>>   - Inclusion of non-normative text
>>   - Document section order
>>   - Document clarity
>>   - Choice of examples
>>   - Example correctness (need to validate against the XSD)
>>
>>
>>
>>
>>
>> -- 
>> to unsubscribe send a message to netconf-request@ops.ietf.org with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 31 11:06:54 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FlSHe-00061H-2h
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 11:06:54 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FlSHb-000669-Ja
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 11:06:54 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FlSDM-000FhQ-CW
	for netconf-data@psg.com; Wed, 31 May 2006 15:02:28 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [47.129.242.57] (helo=zcars04f.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <SCHISHOL@nortel.com>)
	id 1FlSDK-000Fh8-Rh
	for netconf@ops.ietf.org; Wed, 31 May 2006 15:02:27 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4VF2Nv11165
	for <netconf@ops.ietf.org>; Wed, 31 May 2006 11:02:23 -0400 (EDT)
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 WG IETF 66 and Montreal Interim Meeting Agenda (draft)
Date: Wed, 31 May 2006 11:01:32 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B408EEBD21@zcarhxm2.corp.nortel.com>
In-Reply-To: <447DA9BE.3020700@andybierman.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Netconf WG IETF 66 and Montreal Interim Meeting Agenda (draft)
Thread-Index: AcaEwod6pB+txG2WQb+6qCxcIzA7MQAACGtQ
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0

hi

I think we have already identified a number of smaller changes and
corrections. I plan on proposing a modification to Balazs' event class
text which I think we can all agree to incorporate as well. If we get
consensus on other changes, that would be great.=20

Should we aim for mid-June?

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Wednesday, May 31, 2006 10:36 AM
To: Balazs Lengyel
Cc: Netconf (E-mail)
Subject: Re: Netconf WG IETF 66 and Montreal Interim Meeting Agenda
(draft)


Balazs Lengyel wrote:
> I thought (I hoped) that Sharon aims to update the draft before the
> meeting.

Good idea.
We will try to reach consensus on some issues
so there are edits to make.  The authors can
always do bug-fixes as they find them as well.


> Balazs

Andy


>=20
> Andy Bierman wrote:
>> Hi,
>>
>> Here is the first draft of the interim agenda for comment: [resend]
>>
>> ---------------
>>
>> The NETCONF WG will meet at IETF #66, and the Montreal interim=20
>> meeting following, to work on NETCONF Notifications work item.
>>
>> - Interim Meeting Location
>>   IETF Headquarter Hotel: Delta Centre-Ville
>>   777 University Street
>>   Montreal, Quebec, Canada, H3C 3Z7
>>   Hotel WEB site:
>>   http://www.deltahotels.com/hotels/hotels.php?hotelId=3D35
>>
>> - Interim Meeting Times
>>   Friday, July 14, 2006 (1:30 PM - 6:00 PM)
>>   Saturday, July 15, 2006 (9:00 AM - 6:00 PM)
>>
>> - Required Reading
>>   NETCONF Event Notifications
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-0
>> 1.txt
>>
>>
>>
>> The following is a proposed issues list.  The discussion sequence at=20
>> the meetings will generally follow this list, but issues that are=20
>> inter-related may affect the order.  The official WG meeting on July=20
>> 14, 9:00 - 11:30 AM
>> will be used to discuss and prioritize functional requirements.
>>
>>
>> - Functional Requirements
>>   - determine WG consensus on need and priority of Juergen's list
>>     http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications
>>
>> - Architecture
>>
>>   - role of notifications within netconf
>>   - relationship to syslog and snmp notifications
>>   - scaling issues
>>   - security issues (session vs. signed msg, etc.)
>>   - standard RPC methods vs. new RPC methods
>>   - agent resource vs. NMS resource issues
>>
>> - Use within Sessions
>>
>>   - endless RPC
>>   - mixed-mode (rpc operations and notifications)
>>   - single vs. multiple subscriptions within a single session
>>
>>
>> - Transport Specific Support
>>
>>   - use of channels (ssh, beep, what about soap?)
>>   - callhome support for agent initiated sessions
>>
>> - Agent Notification Configuration and Control Mechanism
>>
>>   - config-data vs. subscription-data
>>   - RPCs used to configure and control agent notification generation
>>
>> - Notification Event Classes
>>
>>   - WG consensus on specific list
>>   - Guidelines for selecting classifications
>>
>> - Notification Filtering
>>
>>   - Configuration mechanism(s)
>>   - Agent processing model
>>
>> - Notification Header Content
>>
>>   - Syntax and semantics of data included in all notifications
>>
>> - Standard Notification Content
>>
>>   - WG consensus on 0 or more fully-specified standard notifications
>>   - Full syntax and semantics of each standard notification
>>
>> - Read-only (monitoring) data for agent notification activity
>>
>> - Access Control Issues
>>
>> - Data Model and XSD Issues
>>
>>   - Data model design
>>   - XSD correctness
>>   - Need for 'min-access' and 'max-access'
>>
>> - Documentation Issues
>>
>>   - Terminology
>>   - Inclusion of non-normative text
>>   - Document section order
>>   - Document clarity
>>   - Choice of examples
>>   - Example correctness (need to validate against the XSD)
>>
>>
>>
>>
>>
>> --
>> to unsubscribe send a message to netconf-request@ops.ietf.org with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
>=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: <http://ops.ietf.org/lists/netconf/>


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 31 11:08:50 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FlSAt-0004Rw-Gf
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 10:59:55 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FlRx9-00022A-IQ
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 10:45:44 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FlRpZ-000DRG-Hd
	for netconf-data@psg.com; Wed, 31 May 2006 14:37:53 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FlRpY-000DQw-Gj
	for netconf@ops.ietf.org; Wed, 31 May 2006 14:37:52 +0000
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 984764F0001;
	Wed, 31 May 2006 16:37:51 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 31 May 2006 16:37:50 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 31 May 2006 16:37:49 +0200
Message-ID: <447DAA3D.1080504@ericsson.com>
Date: Wed, 31 May 2006 16:37:49 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: Andy Bierman <andy@andybierman.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Some basic questions on modeling
References: <LYRIS-94329-608557-2006.05.30-10.22.33--balazs.lengyel#ericsson.com@ztcfd0k3.ca.nortel.com> <447C58DF.9080900@ericsson.com> <447C5BA9.2000304@andybierman.com>
In-Reply-To: <447C5BA9.2000304@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 31 May 2006 14:37:49.0829 (UTC) FILETIME=[CA89DB50:01C684BF]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

See inline, Balazs

Andy Bierman wrote:
> Balazs Lengyel wrote:
>>> - we assume that the data model will have multiple roots in as many 
>> namespaces
> 
> what does 'multiple roots' mean?
BALAZS: Maybe the best way to state this is:

The management information model utilizes multiple namespaces. Models in different 
namespaces can be independent of each other in a sense that there is no reference or 
pointers between data in the two namespaces.

> 
>> - we assume real data is always stored in elements not XML attributes 
>> (no subtree filtering on those, no discussion on how operations handle 
>> such data)
> 
> no rule here, but attribute deficiencies are well-documented.
> 

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 31 11:28:29 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FlScX-0002cp-H0
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 11:28:29 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FlScQ-0000G3-2m
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 11:28:29 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FlSWD-000HPG-K0
	for netconf-data@psg.com; Wed, 31 May 2006 15:21:57 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.1
Received: from [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FlSWC-000HP1-S4
	for netconf@ops.ietf.org; Wed, 31 May 2006 15:21:57 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AE17C4F0063
	for <netconf@ops.ietf.org>; Wed, 31 May 2006 17:21:55 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 31 May 2006 17:21:55 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 31 May 2006 17:21:54 +0200
Message-ID: <447DB492.904@ericsson.com>
Date: Wed, 31 May 2006 17:21:54 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Confirmation of configuration
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 31 May 2006 15:21:54.0950 (UTC) FILETIME=[F3274A60:01C684C5]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f

Hello,
During configuration if I do something risky (like restarting the node or switching of an 
interface I might get a back a question do I really want to do this? A sort of confirmation.

1) TO NODE: configure-interface
2) FROM NODE: Confirm action
3) TO NODE: yes do it
4) FROM NODE: OK, done

Is it our aim to support such a configuration flow in netconf or is this the only for 
CLI/GUI interfaces?

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 31 11:36:32 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FlSkK-0005xF-I5
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 11:36:32 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FlSkI-00015p-1V
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 11:36:32 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FlSgO-000IIm-OZ
	for netconf-data@psg.com; Wed, 31 May 2006 15:32:28 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.56] (helo=omr6.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FlSgL-000IIP-VC
	for netconf@ops.ietf.org; Wed, 31 May 2006 15:32:26 +0000
Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69])
	by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k4VFWIco022458
	for <netconf@ops.ietf.org>; Wed, 31 May 2006 11:32:23 -0400
Received: (qmail 3667 invoked by uid 78); 31 May 2006 15:31:50 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.69 with SMTP; 31 May 2006 15:31:50 -0000
Message-ID: <447DB6E0.7030502@andybierman.com>
Date: Wed, 31 May 2006 08:31:44 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Netconf WG IETF 66 and Montreal Interim Meeting Agenda (draft)
References: <713043CE8B8E1348AF3C546DBE02C1B408EEBD21@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B408EEBD21@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
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c

Sharon Chisholm wrote:
> hi
> 
> I think we have already identified a number of smaller changes and
> corrections. I plan on proposing a modification to Balazs' event class
> text which I think we can all agree to incorporate as well. If we get
> consensus on other changes, that would be great. 

Good.
I was hoping we could finish up event classes before the meeting.
The other issue that seems to be finishing up is the use of existing
configuration RPCs instead of new subscription RPCs for conveying
notification generation parameters.

> 
> Should we aim for mid-June?

Mid-June-ish.
How about 9:00 AM EDT, June 19, 2006?

> 
> Sharon

Andy

> 
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
> Behalf Of Andy Bierman
> Sent: Wednesday, May 31, 2006 10:36 AM
> To: Balazs Lengyel
> Cc: Netconf (E-mail)
> Subject: Re: Netconf WG IETF 66 and Montreal Interim Meeting Agenda
> (draft)
> 
> 
> Balazs Lengyel wrote:
>> I thought (I hoped) that Sharon aims to update the draft before the
>> meeting.
> 
> Good idea.
> We will try to reach consensus on some issues
> so there are edits to make.  The authors can
> always do bug-fixes as they find them as well.
> 
> 
>> Balazs
> 
> Andy
> 
> 
>> Andy Bierman wrote:
>>> Hi,
>>>
>>> Here is the first draft of the interim agenda for comment: [resend]
>>>
>>> ---------------
>>>
>>> The NETCONF WG will meet at IETF #66, and the Montreal interim 
>>> meeting following, to work on NETCONF Notifications work item.
>>>
>>> - Interim Meeting Location
>>>   IETF Headquarter Hotel: Delta Centre-Ville
>>>   777 University Street
>>>   Montreal, Quebec, Canada, H3C 3Z7
>>>   Hotel WEB site:
>>>   http://www.deltahotels.com/hotels/hotels.php?hotelId=35
>>>
>>> - Interim Meeting Times
>>>   Friday, July 14, 2006 (1:30 PM - 6:00 PM)
>>>   Saturday, July 15, 2006 (9:00 AM - 6:00 PM)
>>>
>>> - Required Reading
>>>   NETCONF Event Notifications
>>>
>>> http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-0
>>> 1.txt
>>>
>>>
>>>
>>> The following is a proposed issues list.  The discussion sequence at 
>>> the meetings will generally follow this list, but issues that are 
>>> inter-related may affect the order.  The official WG meeting on July 
>>> 14, 9:00 - 11:30 AM
>>> will be used to discuss and prioritize functional requirements.
>>>
>>>
>>> - Functional Requirements
>>>   - determine WG consensus on need and priority of Juergen's list
>>>     http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications
>>>
>>> - Architecture
>>>
>>>   - role of notifications within netconf
>>>   - relationship to syslog and snmp notifications
>>>   - scaling issues
>>>   - security issues (session vs. signed msg, etc.)
>>>   - standard RPC methods vs. new RPC methods
>>>   - agent resource vs. NMS resource issues
>>>
>>> - Use within Sessions
>>>
>>>   - endless RPC
>>>   - mixed-mode (rpc operations and notifications)
>>>   - single vs. multiple subscriptions within a single session
>>>
>>>
>>> - Transport Specific Support
>>>
>>>   - use of channels (ssh, beep, what about soap?)
>>>   - callhome support for agent initiated sessions
>>>
>>> - Agent Notification Configuration and Control Mechanism
>>>
>>>   - config-data vs. subscription-data
>>>   - RPCs used to configure and control agent notification generation
>>>
>>> - Notification Event Classes
>>>
>>>   - WG consensus on specific list
>>>   - Guidelines for selecting classifications
>>>
>>> - Notification Filtering
>>>
>>>   - Configuration mechanism(s)
>>>   - Agent processing model
>>>
>>> - Notification Header Content
>>>
>>>   - Syntax and semantics of data included in all notifications
>>>
>>> - Standard Notification Content
>>>
>>>   - WG consensus on 0 or more fully-specified standard notifications
>>>   - Full syntax and semantics of each standard notification
>>>
>>> - Read-only (monitoring) data for agent notification activity
>>>
>>> - Access Control Issues
>>>
>>> - Data Model and XSD Issues
>>>
>>>   - Data model design
>>>   - XSD correctness
>>>   - Need for 'min-access' and 'max-access'
>>>
>>> - Documentation Issues
>>>
>>>   - Terminology
>>>   - Inclusion of non-normative text
>>>   - Document section order
>>>   - Document clarity
>>>   - Choice of examples
>>>   - Example correctness (need to validate against the XSD)
>>>
>>>
>>>
>>>
>>>
>>> --
>>> to unsubscribe send a message to netconf-request@ops.ietf.org with
>>> the word 'unsubscribe' in a single line as the message text body.
>>> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 31 11:50:48 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FlSy8-0004gC-Hh
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 11:50:48 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FlSy4-0002cX-72
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 11:50:48 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FlSue-000JmG-Mq
	for netconf-data@psg.com; Wed, 31 May 2006 15:47:12 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FlSud-000Jlx-0O
	for netconf@ops.ietf.org; Wed, 31 May 2006 15:47:11 +0000
Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65])
	by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k4VFlAQG022493
	for <netconf@ops.ietf.org>; Wed, 31 May 2006 11:47:10 -0400
Received: (qmail 26579 invoked by uid 78); 31 May 2006 15:43:49 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 31 May 2006 15:43:49 -0000
Message-ID: <447DB9AE.2030305@andybierman.com>
Date: Wed, 31 May 2006 08:43:42 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Confirmation of configuration
References: <447DB492.904@ericsson.com>
In-Reply-To: <447DB492.904@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d

Balazs Lengyel wrote:
> Hello,
> During configuration if I do something risky (like restarting the node 
> or switching of an interface I might get a back a question do I really 
> want to do this? A sort of confirmation.
> 
> 1) TO NODE: configure-interface
> 2) FROM NODE: Confirm action
> 3) TO NODE: yes do it
> 4) FROM NODE: OK, done
> 
> Is it our aim to support such a configuration flow in netconf or is this 
> the only for CLI/GUI interfaces?

No.
This is what we call "screen-scraping".
NETCONF is intended to replace screen-scraping.
You could do this with a state variable
and 2 RPC calls, if you really thought it was important.

> 
> Balazs

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: <http://ops.ietf.org/lists/netconf/>



From owner-netconf@ops.ietf.org Wed May 31 12:27:42 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FlTXq-0005Br-HV
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 12:27:42 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FlTXp-0004wV-7P
	for netconf-archive@lists.ietf.org; Wed, 31 May 2006 12:27:42 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FlTSO-0002HQ-8f
	for netconf-data@psg.com; Wed, 31 May 2006 16:22:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [204.9.221.19] (helo=thingmagic.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <margaret@thingmagic.com>)
	id 1FlTSL-0002HB-Va
	for netconf@ops.ietf.org; Wed, 31 May 2006 16:22:02 +0000
Received: from [66.30.121.250] (account margaret HELO ceili)
  by thingmagic.com (CommuniGate Pro SMTP 5.0.1)
  with ESMTPSA id 1010101; Wed, 31 May 2006 12:22:01 -0400
From: "Margaret Wasserman" <margaret@thingmagic.com>
To: "'Andy Bierman'" <ietf@andybierman.com>,
	"'Balazs Lengyel'" <balazs.lengyel@ericsson.com>
Cc: "'Netconf \(E-mail\)'" <netconf@ops.ietf.org>
Subject: RE: Confirmation of configuration
Date: Wed, 31 May 2006 12:21:59 -0400
Message-ID: <000a01c684ce$584b3110$0202a8c0@corp.devicescape.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.2869
Thread-Index: AcaEyfFnkvbV8AZTTEaI6QersWNAyQAA9Q4w
In-Reply-To: <447DB9AE.2030305@andybierman.com>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0


You could also do this in your end-user application as a front-end to
NETCONF.  If, for instance, your application presents a "delete interface"
button to the end-user, it could confirm that the end-user really wants to
delete the interface before sending the corresponding command via NETCONF.  

On the other hand, if your application doesn't have a user interface and is
running unattended, there is no reason to ask for a confirmation, as the
unattended program will have no one to ask and no reason to change its mind.

Margaret

 

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Wednesday, May 31, 2006 11:44 AM
> To: Balazs Lengyel
> Cc: Netconf (E-mail)
> Subject: Re: Confirmation of configuration
> 
> Balazs Lengyel wrote:
> > Hello,
> > During configuration if I do something risky (like 
> restarting the node 
> > or switching of an interface I might get a back a question 
> do I really 
> > want to do this? A sort of confirmation.
> > 
> > 1) TO NODE: configure-interface
> > 2) FROM NODE: Confirm action
> > 3) TO NODE: yes do it
> > 4) FROM NODE: OK, done
> > 
> > Is it our aim to support such a configuration flow in netconf or is 
> > this the only for CLI/GUI interfaces?
> 
> No.
> This is what we call "screen-scraping".
> NETCONF is intended to replace screen-scraping.
> You could do this with a state variable
> and 2 RPC calls, if you really thought it was important.
> 
> > 
> > Balazs
> 
> 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: <http://ops.ietf.org/lists/netconf/>
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>