From owner-netconf@ops.ietf.org Mon Apr 03 08:42:12 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQONo-000068-KH
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 08:42:12 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQONn-0000PD-5m
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 08:42:12 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQOHV-00052s-I3
	for netconf-data@psg.com; Mon, 03 Apr 2006 12:35: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.129.242.56] (helo=zcars04e.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FQOHU-00051y-Ei
	for netconf@ops.ietf.org; Mon, 03 Apr 2006 12:35:40 +0000
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k33CV6q18131
	for <netconf@ops.ietf.org>; Mon, 3 Apr 2006 08:31:07 -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: again about interim
Date: Mon, 3 Apr 2006 08:35:34 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407AB91EE@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: again about interim
Thread-Index: AcZU79I4tN9ygNRRSIiw+3uiM7kgsQCKsagA
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.1 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22


<Andy>

Dave H. and I are particularly concerned about this architecture thing.
There doesn't seem to be any. How does this all fit with our RPC-based
configuration datastore manipulation protocol?  What is the extensible
framework that allows the maximum standards features for
interoperability, plus a content-independent data payload capability?
What are the components needed immediately (vs. phased in) to deploy a
robust, secure, efficient, and interoperable notification mechanism?

</Andy>

The architecture is the Netconf architecture. How this work fits in is
shown in the updated to the layer diagram (replace <rpc-one-way> with
something more like <one-way-message> as one way to resolve unofficial
issue #1 when you read it though). Other bits of interaction with the
Netconf architecture are explained in other parts of the draft

What specifically is seem to be missing?


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 Apr 03 08:54:45 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQOZx-0007VY-Gu
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 08:54:45 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQOZx-0000kg-8b
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 08:54:45 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQOVr-0005wf-0D
	for netconf-data@psg.com; Mon, 03 Apr 2006 12:50: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 [47.129.242.56] (helo=zcars04e.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FQOVq-0005wS-5X
	for netconf@ops.ietf.org; Mon, 03 Apr 2006 12:50:30 +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 k33Cjuq20109
	for <netconf@ops.ietf.org>; Mon, 3 Apr 2006 08:45:56 -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: requirement: agent initiated session support
Date: Mon, 3 Apr 2006 08:50:21 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407AB9238@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: requirement: agent initiated session support
Thread-Index: AcZU0VJvnCTmgh1DQ8m6JYT+wh2y2AAD2dYgAI7uhQA=
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.1 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370

hi

<Andy and Hector discussing call-home deleted>

Doesn't the call-home stuff in the Beep draft just specify that the
agent initiates the connection, but then that normal roles resume?
Wouldn't that be what we would be looking for here? Is the discussion
about NAT traversal or are we trying to address another use case here?
Before we go down the road of making things more complicated, I just
want to understand the use cases.

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 Apr 03 09:32:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQPAq-0007PC-UX
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 09:32:52 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQPAq-0002wD-HA
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 09:32:52 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQP5u-0008LZ-Sa
	for netconf-data@psg.com; Mon, 03 Apr 2006 13:27:46 +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 1FQP5t-0008LG-Lw
	for netconf@ops.ietf.org; Mon, 03 Apr 2006 13:27:45 +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 k33DRfU11293
	for <netconf@ops.ietf.org>; Mon, 3 Apr 2006 09:27:41 -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: requirement: notification content self-containment
Date: Mon, 3 Apr 2006 09:27:39 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407AB930A@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: requirement: notification content self-containment
Thread-Index: AcZU1EBKsgnRADrQQECb3XQzqswc/gCSfe1w
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.1 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69


<Andy>

It should be a requirement that the notification message
will contain enough header data to fully decode the notification.  Info
from the session, connection, or other notifications must not be
required for an application to decode the notification contents.

This has 2 important implications:

1) There is no real reason the notifications need to come back
   on the same session that RPC operations occurred  which
   possibly caused the notifications.
</Andy>

This doesn't really follow from the requirement, but are you suggesting
a design alternative that when I create a subscription, I specify which
Netconf session to send things to? That could be a fun attack to=20

<Andy>
2) Session parameters such as the subscription-id need to be
   replaced with parameters that have meaning to a general
   application.  This is important if the notifications are
   being logged or centrally processed by a 3rd party application.
<Andy>

If I have the subscription id, why do I need the session ID? I also
wouldn't think a third party would use either the session Id or the
subscription id in their log. They are both transient and only unique
within the context of an NE. It would prefer identifiers like device
name (or IP) and perhaps some other fields.

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/>


--
to 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 Apr 03 10:07:25 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQPiH-0003Wb-Ae
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 10:07:25 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQPiF-0004Bl-TK
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 10:07:25 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQPcs-000ATX-OR
	for netconf-data@psg.com; Mon, 03 Apr 2006 14:01: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.55] (helo=zrtps0kn.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FQPcr-000AT9-GR
	for netconf@ops.ietf.org; Mon, 03 Apr 2006 14:01:49 +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 k33E1jD10056
	for <netconf@ops.ietf.org>; Mon, 3 Apr 2006 10:01:45 -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: requirement: agent initiated session support
Date: Mon, 3 Apr 2006 10:01:41 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407AB940C@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: requirement: agent initiated session support
Thread-Index: AcZU0USMOkaPEpdiQoWx168A7hg8GwCVOd8A
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.1 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f


<Andy>
>> 2) get rid of all the parameters in the start-notifications
>>    or modify-subscription except the profileName (index)
>>
>> This way agents and managers can both share the profiles
>> and the manager won't reenter the same data in the most complex=20
>> manner possible every time.  I can configure the agent to connect to=20
>> notification receiver X using profile Y.  The manager can just=20
>> subscribe using profile Y.
>>
>> (An agent may not allow a profile in use to be modified.)
</Andy>

As a manager who actually supported Notification subscription in SNMP, I
hated the pre-configured approach for two reasons:

1) It was way too complicated. It was spread out over 100 tables with
far too many options. Even the case you used 99 times out of 100 was a
lot of work. You would get it to work for some devices, then find one
where it didn't work and realize that you forgot to create a row in yet
another table. I like the idea of command-line options since it acts as
a deterrent from over-engineering the subscription model

2) It was persistent. I had to always check if I was already set up to
get notifications from the box. This was more annoying then it sounds.

Plus, in a connection-oriented model, would we have the idea of
subscriptions that were there, but not active for when the underlying
session died?

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 Apr 03 10:16:08 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQPqi-00008l-Es
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 10:16:08 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQPqi-0004b8-5U
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 10:16:08 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQPmC-000BEd-MA
	for netconf-data@psg.com; Mon, 03 Apr 2006 14:11: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,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 1FQPmB-000BEO-Ot
	for netconf@ops.ietf.org; Mon, 03 Apr 2006 14:11: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 k33EBOt29082
	for <netconf@ops.ietf.org>; Mon, 3 Apr 2006 10:11:24 -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: requirement: agent initiated session support
Date: Mon, 3 Apr 2006 10:11:12 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407AB9448@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: requirement: agent initiated session support
Thread-Index: AcZU0USMOkaPEpdiQoWx168A7hg8GwCVOd8AAABpoBA=
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.1 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5

hi

I'm now responding to myself, but anyways ....

<Sharon>

<Andy>
>> 2) get rid of all the parameters in the start-notifications
>>    or modify-subscription except the profileName (index)
>>
>> This way agents and managers can both share the profiles
>> and the manager won't reenter the same data in the most complex
>> manner possible every time.  I can configure the agent to connect to=20
>> notification receiver X using profile Y.  The manager can just=20
>> subscribe using profile Y.
>>
>> (An agent may not allow a profile in use to be modified.)
</Andy>

As a manager who actually supported Notification subscription in SNMP, I
hated the pre-configured approach for two reasons:

1) It was way too complicated. It was spread out over 100 tables with
far too many options. Even the case you used 99 times out of 100 was a
lot of work. You would get it to work for some devices, then find one
where it didn't work and realize that you forgot to create a row in yet
another table. I like the idea of command-line options since it acts as
a deterrent from over-engineering the subscription model

2) It was persistent. I had to always check if I was already set up to
get notifications from the box. This was more annoying then it sounds.
</Sharon

I think part of the problem here is who is the authoritative source of
'what the netconf client is interested in'. The netconf server is the
authoritative source of device configuration. The Netconf client is the
authoritative source of what synchronous commands it wants response
from, but suddenly with asynchronous messaging, we are proposing that
the netconf server is the authoritative source of what the netconf
client is interested in? This is annoying as a client. It's more work
and a loss of control.

<Sharon>
Plus, in a connection-oriented model, would we have the idea of
subscriptions that were there, but not active for when the underlying
session died?

</Sharon>

I

--
to 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 Apr 03 10:29:53 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQQ41-0006xw-8L
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 10:29:53 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQQ40-0004wT-Tg
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 10:29:53 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQPz8-000CBN-PC
	for netconf-data@psg.com; Mon, 03 Apr 2006 14:24: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.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 1FQPz7-000CBB-Ls
	for netconf@ops.ietf.org; Mon, 03 Apr 2006 14:24:49 +0000
Received: from mail.networksolutionsemail.com (omr5.mgt.bos.netsol.com [10.49.2.115] (may be forged))
	by ns-omrbm5.netsolmail.com (8.12.10/8.12.10) with SMTP id k33EOmDT001040
	for <netconf@ops.ietf.org>; Mon, 3 Apr 2006 10:24:48 -0400
Received: (qmail 32518 invoked by uid 78); 3 Apr 2006 14:24:47 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.115 with SMTP; 3 Apr 2006 14:24:47 -0000
Message-ID: <44313029.80106@andybierman.com>
Date: Mon, 03 Apr 2006 07:24:41 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: requirement: notification content self-containment
References: <713043CE8B8E1348AF3C546DBE02C1B407AB930A@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B407AB930A@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: 244a2fd369eaf00ce6820a760a3de2e8

Sharon Chisholm wrote:
> <Andy>
> 
> It should be a requirement that the notification message
> will contain enough header data to fully decode the notification.  Info
> from the session, connection, or other notifications must not be
> required for an application to decode the notification contents.
> 
> This has 2 important implications:
> 
> 1) There is no real reason the notifications need to come back
>    on the same session that RPC operations occurred  which
>    possibly caused the notifications.
> </Andy>
> 
> This doesn't really follow from the requirement, but are you suggesting
> a design alternative that when I create a subscription, I specify which
> Netconf session to send things to? That could be a fun attack to 
> 
> <Andy>
> 2) Session parameters such as the subscription-id need to be
>    replaced with parameters that have meaning to a general
>    application.  This is important if the notifications are
>    being logged or centrally processed by a 3rd party application.
> <Andy>
> 
> If I have the subscription id, why do I need the session ID? I also
> wouldn't think a third party would use either the session Id or the
> subscription id in their log. They are both transient and only unique
> within the context of an NE. It would prefer identifiers like device
> name (or IP) and perhaps some other fields.


Session IDs and subscription IDs get used over and over again.
They make bad parameters for saving and passing to other apps.

(session 4, subscription 1) has no uniqueness over time within
1 agent, and has no uniqueness at all across agents.

> 
> 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/>
> 
> 


--
to 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 Apr 03 10:49:50 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQQNJ-00045n-Uk
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 10:49:49 -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 1FQQNJ-0005Tp-T6
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 10:49:49 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FQQBu-0001ZZ-QW
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 10:38:04 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQQ6Q-000CkB-2v
	for netconf-data@psg.com; Mon, 03 Apr 2006 14:32: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.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FQQ6P-000Cjp-6f
	for netconf@ops.ietf.org; Mon, 03 Apr 2006 14:32:21 +0000
Received: from mail.networksolutionsemail.com (omr2.mgt.bos.netsol.com [10.49.2.112] (may be forged))
	by ns-omrbm2.netsolmail.com (8.12.10/8.12.10) with SMTP id k33EWJvW016238
	for <netconf@ops.ietf.org>; Mon, 3 Apr 2006 10:32:19 -0400
Received: (qmail 12955 invoked by uid 78); 3 Apr 2006 14:32:19 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.112 with SMTP; 3 Apr 2006 14:32:19 -0000
Message-ID: <443131ED.60402@andybierman.com>
Date: Mon, 03 Apr 2006 07:32:13 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: requirement: agent initiated session support
References: <713043CE8B8E1348AF3C546DBE02C1B407AB9448@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B407AB9448@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.3 (-)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024

Sharon Chisholm wrote:
> hi
> 
> I'm now responding to myself, but anyways ....
> 
> <Sharon>
> 
> <Andy>
>>> 2) get rid of all the parameters in the start-notifications
>>>    or modify-subscription except the profileName (index)
>>>
>>> This way agents and managers can both share the profiles
>>> and the manager won't reenter the same data in the most complex
>>> manner possible every time.  I can configure the agent to connect to 
>>> notification receiver X using profile Y.  The manager can just 
>>> subscribe using profile Y.
>>>
>>> (An agent may not allow a profile in use to be modified.)
> </Andy>
> 


Good luck with your model in an actual network after a power outage.
In the subscribe model, none of the agents can send any notifications
until a manager connects to them and asks for notifications.  The startup
notifications are critical to have, to check for any
config/image/HW mismatches that occurred during boot-up.

IMO, this approach is complicated -- not the traditional model.
There will probably be 2 or 3 tables, not 100.
I never said "over-engineer it to death" like SNMP did.

Andy



> As a manager who actually supported Notification subscription in SNMP, I
> hated the pre-configured approach for two reasons:
> 
> 1) It was way too complicated. It was spread out over 100 tables with
> far too many options. Even the case you used 99 times out of 100 was a
> lot of work. You would get it to work for some devices, then find one
> where it didn't work and realize that you forgot to create a row in yet
> another table. I like the idea of command-line options since it acts as
> a deterrent from over-engineering the subscription model
> 
> 2) It was persistent. I had to always check if I was already set up to
> get notifications from the box. This was more annoying then it sounds.
> </Sharon
> 
> I think part of the problem here is who is the authoritative source of
> 'what the netconf client is interested in'. The netconf server is the
> authoritative source of device configuration. The Netconf client is the
> authoritative source of what synchronous commands it wants response
> from, but suddenly with asynchronous messaging, we are proposing that
> the netconf server is the authoritative source of what the netconf
> client is interested in? This is annoying as a client. It's more work
> and a loss of control.
> 
> <Sharon>
> Plus, in a connection-oriented model, would we have the idea of
> subscriptions that were there, but not active for when the underlying
> session died?
> 
> </Sharon>
> 
> I
> 
> --
> to 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 Apr 03 11:21:58 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQQsQ-0003yP-In
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 11:21:58 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQQsP-0006pS-8M
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 11:21:58 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQQo4-000Fzo-IK
	for netconf-data@psg.com; Mon, 03 Apr 2006 15:17: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.56] (helo=zcars04e.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FQQo3-000FzW-IF
	for netconf@ops.ietf.org; Mon, 03 Apr 2006 15:17:27 +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 k33FCsq17838
	for <netconf@ops.ietf.org>; Mon, 3 Apr 2006 11:12:55 -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: requirement: agent initiated session support
Date: Mon, 3 Apr 2006 11:17:23 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407B47805@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: requirement: agent initiated session support
Thread-Index: AcZXMTNoOA/kXY2ISVeEWRMtBwfkmgAABBdg
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.1 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024

hi

This is similar to the event replay work we have done. Our method works
fine without persistent subscriptions. The user creates a new
subscription with a timestamp that indicates the start of the replay
window and the other parameters it sends when it creates a normal
subscription.

We didn't include it in the draft since we felt it could be done later
as an optional capability.

Is there interest in including replay in release one?

Sharon

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]=20
Sent: Monday, April 03, 2006 11:13 AM
To: Phil Shafer
Cc: Chisholm, Sharon [CAR:ZZ00:EXCH]; Netconf (E-mail)
Subject: Re: requirement: agent initiated session support


Phil Shafer wrote:
> Andy Bierman writes:
>> In the subscribe model, none of the agents can send any notifications

>> until a manager connects to them and asks for notifications.  The=20
>> startup notifications are critical to have, to check for any=20
>> config/image/HW mismatches that occurred during boot-up.
>=20
> We do this with our accounting-profiles RPC (which I'm planning on=20
> mimicing for syslog data) with a combination of the <realtime/> flag=20
> and the <since>timestamp</since argument.  The system makes local=20
> copies of accounting records and can serve them up with a starting=20
> window, in realtime, or as a combination, where the records since the=20
> given timestamp are passed along and then the RPC switches to=20
> realtime.
>=20
>   <rpc>  <!-- from memory; check docs for accurate details -->
>     <get-accounting-records>
>       <since>YYYY-MM-DD.HH:MM:SS</since>
>       <realtime/>
>     </get-accounting-records>
>   </rpc>


I like this!  (Reminds me of RMON TimeFilter ;-)

I assume there are some config parameters
to setup logging somewhere else.  If <realtime/> is
missing then the <rpc> finishes when all saved notifications have been
delivered. If present, then the <rpc> never finishes, and (in this
example) new notifications may be interleaved with saved notifications,
so the manager needs to check the timestamp as usual.

What about making it a generic RPC:

  <rpc>
    <get-log-records>
       <type>accounting</type>    <!-- or syslog or whatever -->
       <since>YYYY-MM-DD.HH:MM:SS</since>
       <realtime/>
    </get-log-records>
  </rpc>

>=20
> Thanks,
>  Phil
>=20
>=20

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 Apr 03 11:41:10 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQRB0-0000mu-FN
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 11:41:10 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQRAz-0007gh-6C
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 11:41:10 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQR7M-000Hay-55
	for netconf-data@psg.com; Mon, 03 Apr 2006 15: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.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.50] (helo=omr1.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FQR7L-000Ham-7t
	for netconf@ops.ietf.org; Mon, 03 Apr 2006 15:37:23 +0000
Received: from mail.networksolutionsemail.com (omr1.mgt.bos.netsol.com [10.49.2.111] (may be forged))
	by omr1.networksolutionsemail.com (8.12.10/8.12.10) with SMTP id k33FbMZj020413
	for <netconf@ops.ietf.org>; Mon, 3 Apr 2006 11:37:22 -0400
Received: (qmail 18104 invoked by uid 78); 3 Apr 2006 15:37:21 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.111 with SMTP; 3 Apr 2006 15:37:21 -0000
Message-ID: <4431412B.5000506@andybierman.com>
Date: Mon, 03 Apr 2006 08:37:15 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: requirement: agent initiated session support
References: <713043CE8B8E1348AF3C546DBE02C1B407B47805@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B407B47805@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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Sharon Chisholm wrote:
> hi
> 
> This is similar to the event replay work we have done. Our method works
> fine without persistent subscriptions. The user creates a new
> subscription with a timestamp that indicates the start of the replay
> window and the other parameters it sends when it creates a normal
> subscription.
> 
> We didn't include it in the draft since we felt it could be done later
> as an optional capability.
> 
> Is there interest in including replay in release one?

I'm interested in implementing what Phil is suggesting,
not the mechanisms in the current draft.

> 
> 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 Apr 03 11:42:10 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQRBy-0000ui-JV
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 11:42:10 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQRBx-0007jC-AL
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 11:42:10 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQR91-000Hin-LZ
	for netconf-data@psg.com; Mon, 03 Apr 2006 15:39: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 [47.140.192.56] (helo=zrtps0kp.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FQR90-000HiT-SV
	for netconf@ops.ietf.org; Mon, 03 Apr 2006 15:39:07 +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 k33Fd2U25119
	for <netconf@ops.ietf.org>; Mon, 3 Apr 2006 11:39:02 -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: requirement: agent initiated session support
Date: Mon, 3 Apr 2006 11:38:59 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407B478B4@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: requirement: agent initiated session support
Thread-Index: AcZXNINFdFyE+CmWROqOFsKdxIicFAAACpRw
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.1 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4

hi

There is no mechanism for replay in the current draft.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]=20
Sent: Monday, April 03, 2006 11:37 AM
To: Chisholm, Sharon [CAR:ZZ00:EXCH]
Cc: Netconf (E-mail)
Subject: Re: requirement: agent initiated session support


Sharon Chisholm wrote:
> hi
>=20
> This is similar to the event replay work we have done. Our method=20
> works fine without persistent subscriptions. The user creates a new=20
> subscription with a timestamp that indicates the start of the replay=20
> window and the other parameters it sends when it creates a normal=20
> subscription.
>=20
> We didn't include it in the draft since we felt it could be done later

> as an optional capability.
>=20
> Is there interest in including replay in release one?

I'm interested in implementing what Phil is suggesting,
not the mechanisms in the current draft.

>=20
> 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 Apr 03 11:43:47 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQRDX-0001HX-HU
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 11:43:47 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQRDW-0007qY-8J
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 11:43:47 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQRAM-000HrI-0p
	for netconf-data@psg.com; Mon, 03 Apr 2006 15:40: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.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 1FQQCI-000DId-6c
	for netconf@ops.ietf.org; Mon, 03 Apr 2006 14:38:26 +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 k33EcND17472
	for <netconf@ops.ietf.org>; Mon, 3 Apr 2006 10:38: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: requirement: agent initiated session support
Date: Mon, 3 Apr 2006 10:38:22 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407AB9509@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: requirement: agent initiated session support
Thread-Index: AcZXK27MNkcDjt4SSoSG12n7OsN2GAAAB1Cw
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.1 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17

<Andy>

Good luck with your model in an actual network after a power outage. In
the subscribe model, none of the agents can send any notifications until
a manager connects to them and asks for notifications.  The startup
notifications are critical to have, to check for any config/image/HW
mismatches that occurred during boot-up.
</Andy>

If a tree falls in the forest ... what's the point of someone sending
out notifications if no one is listening to them? How exactly would that
work in the absence of a Netconf session anyways? (Note that on-device
logging and replay works fine with non-persistent subscriptions)

<Andy>
IMO, this approach is complicated -- not the traditional model. There
will probably be 2 or 3 tables, not 100. I never said "over-engineer it
to death" like SNMP did.
</Andy>

How is not requiring persistency more complicated?

Yes, there are always ways to keep things simple in theory. My favourite
is that if we do decide to allow persistency, that we also keep the
command line options.=20

Sharon
=3D



--
to 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 Apr 03 11:44:37 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQREL-0001NV-O6
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 11:44:37 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQREK-0007sz-E7
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 11:44:37 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQRAe-000Hw4-5w
	for netconf-data@psg.com; Mon, 03 Apr 2006 15:40: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 [205.178.146.54] (helo=ns-omrbm4.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FQQkP-000FgZ-Fd
	for netconf@ops.ietf.org; Mon, 03 Apr 2006 15:13:42 +0000
Received: from mail.networksolutionsemail.com (omr4.mgt.bos.netsol.com [10.49.2.114] (may be forged))
	by ns-omrbm4.netsolmail.com (8.12.10/8.12.10) with SMTP id k33FDdQ3008651
	for <netconf@ops.ietf.org>; Mon, 3 Apr 2006 11:13:40 -0400
Received: (qmail 4245 invoked by uid 78); 3 Apr 2006 15:13:39 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.114 with SMTP; 3 Apr 2006 15:13:39 -0000
Message-ID: <44313B97.2050704@andybierman.com>
Date: Mon, 03 Apr 2006 08:13:27 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
CC: Sharon Chisholm <schishol@nortel.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: requirement: agent initiated session support
References: <200604031452.k33EqZYE087783@idle.juniper.net>
In-Reply-To: <200604031452.k33EqZYE087783@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: f4c2cf0bccc868e4cc88dace71fb3f44

Phil Shafer wrote:
> Andy Bierman writes:
>> In the subscribe model, none of the agents can send any notifications
>> until a manager connects to them and asks for notifications.  The startup
>> notifications are critical to have, to check for any
>> config/image/HW mismatches that occurred during boot-up.
> 
> We do this with our accounting-profiles RPC (which I'm planning on
> mimicing for syslog data) with a combination of the <realtime/>
> flag and the <since>timestamp</since argument.  The system makes
> local copies of accounting records and can serve them up with a
> starting window, in realtime, or as a combination, where the records
> since the given timestamp are passed along and then the RPC switches
> to realtime.
> 
>   <rpc>  <!-- from memory; check docs for accurate details -->
>     <get-accounting-records>
>       <since>YYYY-MM-DD.HH:MM:SS</since>
>       <realtime/>
>     </get-accounting-records>
>   </rpc>


I like this!  (Reminds me of RMON TimeFilter ;-)

I assume there are some config parameters
to setup logging somewhere else.  If <realtime/> is
missing then the <rpc> finishes when all saved notifications
have been delivered. If present, then the <rpc> never finishes,
and (in this example) new notifications may be interleaved
with saved notifications, so the manager needs to check the
timestamp as usual.

What about making it a generic RPC:

  <rpc>
    <get-log-records>
       <type>accounting</type>    <!-- or syslog or whatever -->
       <since>YYYY-MM-DD.HH:MM:SS</since>
       <realtime/>
    </get-log-records>
  </rpc>

> 
> 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 Apr 03 11:44:53 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQREb-0001QI-EE
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 11:44:53 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQREa-0007tn-4v
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 11:44:53 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQRAU-000Ht8-0c
	for netconf-data@psg.com; Mon, 03 Apr 2006 15:40: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 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 1FQQL9-000Dvo-Td
	for netconf@ops.ietf.org; Mon, 03 Apr 2006 14:47:35 +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 k33ElU1Z072957;
	Mon, 3 Apr 2006 07:47:30 -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 k33ElM541678;
	Mon, 3 Apr 2006 07:47: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 k33EqZYE087783;
	Mon, 3 Apr 2006 10:52:35 -0400 (EDT)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200604031452.k33EqZYE087783@idle.juniper.net>
To: Andy Bierman <ietf@andybierman.com>
cc: Sharon Chisholm <schishol@nortel.com>,
   "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: requirement: agent initiated session support 
In-Reply-To: Your message of "Mon, 03 Apr 2006 07:32:13 PDT."
             <443131ED.60402@andybierman.com> 
Date: Mon, 03 Apr 2006 10:52:35 -0400
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a

Andy Bierman writes:
>In the subscribe model, none of the agents can send any notifications
>until a manager connects to them and asks for notifications.  The startup
>notifications are critical to have, to check for any
>config/image/HW mismatches that occurred during boot-up.

We do this with our accounting-profiles RPC (which I'm planning on
mimicing for syslog data) with a combination of the <realtime/>
flag and the <since>timestamp</since argument.  The system makes
local copies of accounting records and can serve them up with a
starting window, in realtime, or as a combination, where the records
since the given timestamp are passed along and then the RPC switches
to realtime.

  <rpc>  <!-- from memory; check docs for accurate details -->
    <get-accounting-records>
      <since>YYYY-MM-DD.HH:MM:SS</since>
      <realtime/>
    </get-accounting-records>
  </rpc>

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 Apr 03 11:47:21 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQRGz-0001k6-Iy
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 11:47:21 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQRGz-0007ze-6i
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 11:47:21 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQRDR-000IJz-Lv
	for netconf-data@psg.com; Mon, 03 Apr 2006 15:43: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=BAYES_00,FORGED_RCVD_HELO 
	autolearn=ham version=3.1.1
Received: from [193.0.0.176] (helo=saturn.time-travellers.org)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <shane@isc.org>)
	id 1FQRDQ-000IJc-KP
	for netconf@ops.ietf.org; Mon, 03 Apr 2006 15:43:40 +0000
Received: from shane-laptop.time-travellers.org (kerr.xs4all.nl [82.93.59.73])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by saturn.time-travellers.org (Postfix) with ESMTP id 96F5E1471BF
	for <netconf@ops.ietf.org>; Mon,  3 Apr 2006 17:43:38 +0200 (CEST)
From: Shane Kerr <shane@isc.org>
Reply-To: shane_kerr@isc.org
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
Subject: Re: requirement: agent initiated session support
Date: Mon, 3 Apr 2006 17:43:26 +0200
User-Agent: KMail/1.8.3
References: <713043CE8B8E1348AF3C546DBE02C1B407B47805@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B407B47805@zcarhxm2.corp.nortel.com>
Organization: ISC
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200604031743.26108.shane@isc.org>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c

On Monday 03 April 2006 17:17, Sharon Chisholm wrote:
> hi
>
> This is similar to the event replay work we have done. Our method
> works fine without persistent subscriptions. The user creates a new
> subscription with a timestamp that indicates the start of the
> replay window and the other parameters it sends when it creates a
> normal subscription.
>
> We didn't include it in the draft since we felt it could be done
> later as an optional capability.
>
> Is there interest in including replay in release one?

I had actually been considering the replay idea previously, although 
my take on it was surely different from yours. My thinking was that 
having replay would make the need for mixing command and notification 
channels. Here's the idea:

client -> subscribe for (a, b, c), begin anywhere
server <- event a, #121
server <- event c, #122
server <- event b, #123

At this point, the client wants to change the subscription because 
something interesting happened. So it can create a new channel, and:

client -> subscribe for (a, b, c, d), begin at 124
server <- event a, #124
   .
   .
   .

Of course, this isn't the only purpose for it. It would be useful at 
any time when a client lost connection for a while. Consider the case 
where the client (or server) lost an interface. If you could specify 
the event to start at, then you would be able to transparently live 
through disconnects.

Also, I don't have a problem with using a timestamp, although I think 
using a server-specified increasing number might make more sense. 
Otherwise a client will have to filter go back to the previous second 
and filter out duplicates, if there are multiple events per second.

--
Shane

--
to 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 Apr 03 12:25:54 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQRsI-0006Ov-BN
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 12:25:54 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQRsH-0001Qt-1I
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 12:25:54 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQRoG-000L2c-G5
	for netconf-data@psg.com; Mon, 03 Apr 2006 16:21: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.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FQRoF-000L2O-JZ
	for netconf@ops.ietf.org; Mon, 03 Apr 2006 16:21:43 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k33GLfts005858
	for <netconf@ops.ietf.org>; Mon, 3 Apr 2006 12:21:42 -0400
Received: (qmail 32020 invoked by uid 78); 3 Apr 2006 16:21:41 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.113 with SMTP; 3 Apr 2006 16:21:41 -0000
Message-ID: <44314B8E.4050301@andybierman.com>
Date: Mon, 03 Apr 2006 09:21:34 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: requirement: agent initiated session support
References: <713043CE8B8E1348AF3C546DBE02C1B407B478B4@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B407B478B4@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: 02ec665d00de228c50c93ed6b5e4fc1a

Sharon Chisholm wrote:
> hi
> 
> There is no mechanism for replay in the current draft.

I meant the whole thing.
Phil is suggesting an endless-RPC if the <realtime/>
parameter is included.  IMO this is a nice simple approach.
The manager connects and gets new and 'old-since-time-X'
in the same RPC.  It can fill the data gap and keep going
in 1 easy step.

> 
> Sharon

Andy

> 
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com] 
> Sent: Monday, April 03, 2006 11:37 AM
> To: Chisholm, Sharon [CAR:ZZ00:EXCH]
> Cc: Netconf (E-mail)
> Subject: Re: requirement: agent initiated session support
> 
> 
> Sharon Chisholm wrote:
>> hi
>>
>> This is similar to the event replay work we have done. Our method 
>> works fine without persistent subscriptions. The user creates a new 
>> subscription with a timestamp that indicates the start of the replay 
>> window and the other parameters it sends when it creates a normal 
>> subscription.
>>
>> We didn't include it in the draft since we felt it could be done later
> 
>> as an optional capability.
>>
>> Is there interest in including replay in release one?
> 
> I'm interested in implementing what Phil is suggesting,
> not the mechanisms in the current draft.
> 
>> 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 Mon Apr 03 12:44:04 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQS9s-0004bz-FP
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 12:44:04 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQS9r-0002MU-5D
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 12:44:04 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQS5t-000M8D-Ld
	for netconf-data@psg.com; Mon, 03 Apr 2006 16:39: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 1FQS5s-000M7x-HX
	for netconf@ops.ietf.org; Mon, 03 Apr 2006 16:39: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 k33GdrD09258
	for <netconf@ops.ietf.org>; Mon, 3 Apr 2006 12:39:54 -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: requirement: agent initiated session support
Date: Mon, 3 Apr 2006 12:39:50 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407B47A01@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: requirement: agent initiated session support
Thread-Index: AcZXOrWGMKPoSyiPTX6q9/cMP/a9BgAAjj3g
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.1 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8

hi

You don't need the end-less RPC thing for replay. You can use the same
message delivery mechanism for the replayed notifications as the
real-time ones. There are advantages to this continuity. You just need a
mechanism to let the client know the replay is completed. We opted for a
notification.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]=20
Sent: Monday, April 03, 2006 12:22 PM
To: Chisholm, Sharon [CAR:ZZ00:EXCH]
Cc: Netconf (E-mail)
Subject: Re: requirement: agent initiated session support


Sharon Chisholm wrote:
> hi
>=20
> There is no mechanism for replay in the current draft.

I meant the whole thing.
Phil is suggesting an endless-RPC if the <realtime/>
parameter is included.  IMO this is a nice simple approach.
The manager connects and gets new and 'old-since-time-X'
in the same RPC.  It can fill the data gap and keep going
in 1 easy step.

>=20
> Sharon

Andy

>=20
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com]
> Sent: Monday, April 03, 2006 11:37 AM
> To: Chisholm, Sharon [CAR:ZZ00:EXCH]
> Cc: Netconf (E-mail)
> Subject: Re: requirement: agent initiated session support
>=20
>=20
> Sharon Chisholm wrote:
>> hi
>>
>> This is similar to the event replay work we have done. Our method
>> works fine without persistent subscriptions. The user creates a new=20
>> subscription with a timestamp that indicates the start of the replay=20
>> window and the other parameters it sends when it creates a normal=20
>> subscription.
>>
>> We didn't include it in the draft since we felt it could be done=20
>> later
>=20
>> as an optional capability.
>>
>> Is there interest in including replay in release one?
>=20
> I'm interested in implementing what Phil is suggesting,
> not the mechanisms in the current draft.
>=20
>> Sharon
>=20
> Andy
>=20
>=20
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with the

> word 'unsubscribe' in a single line as the message text body.
> archive: <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 Apr 03 15:25:27 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQUg3-0004W6-6F
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 15:25:27 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQUg2-0000UC-Oi
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 15:25:27 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQUbH-0007s2-7x
	for netconf-data@psg.com; Mon, 03 Apr 2006 19:20: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.120] (helo=kremlin.juniper.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <kwatsen@juniper.net>)
	id 1FQUbG-0007rq-FR
	for netconf@ops.ietf.org; Mon, 03 Apr 2006 19:20:30 +0000
Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25])
  by kremlin.juniper.net with ESMTP; 03 Apr 2006 12:20:30 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.03,159,1141632000"; 
   d="scan'208"; a="537577797:sNHT25493044"
Received: from antitop.jnpr.net ([172.24.15.27]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 3 Apr 2006 12:20:29 -0700
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: requirement: agent initiated session support
Date: Mon, 3 Apr 2006 12:20:29 -0700
Message-ID: <B8C821F9E0675D44BFA994C28C0120E5E25053@antitop.jnpr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: requirement: agent initiated session support
Thread-Index: AcZXMTNoOA/kXY2ISVeEWRMtBwfkmgAABBdgAAUWy7A=
From: "Kent Watsen" <kwatsen@juniper.net>
To: "Sharon Chisholm" <schishol@nortel.com>,
	"Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 03 Apr 2006 19:20:29.0451 (UTC) FILETIME=[AB4D4DB0:01C65753]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3


Sharon wrote:
> Is there interest in including replay in release one?

I would like to see "replay" included as part of release one.



More importantly, though, since there continues to be confusion=20
regarding requirements and real-world use cases - let me try again:


1. Agent-initiated connections (must-have)

   NSM supports both outbound connections to the device as well as=20
   listening for inbound connections from the devices - all connections=20
   use a multi-channeling transport.  Regardless of which peer initiates
   the underlying connection, NSM always assumes the role of "client"
   and the device always assumes the role of "server" - this is for=20
   every protocol the connection multiplexes including crypto-setup,=20
   auth, channel opening/closing, and a bunch of proprietary
configuration
   and notification protocols we implemented because the current
standards
   don't meet our needs [but NetConf has the potential to fix]


2. Subscription-based filters (must-have, for high-volume logging only)

   NSM's current logging protocol supports subscription-based filters=20
   as some of Juniper's devices would otherwise have an unmanageable
   logging rate.  Depending on the application, only a subset of all
   notifications are interesting - for instance, a fault-analyzer only
   cares for fault-related logs and a security-analyzer only cares about
   traffic-related events.  The obvious purpose for device-side
filtering
   is to improve the signal-to-noise ratio, which in turn enables the
   application to scale better.

   All that said, I do NOT think that NetConf Notifications should ever=20
   be used for high-volume throughput logging - XML is way too expensive

   for that.  If Netconf Notifications are limited to just
configuration-
   changes, then the need for device-side filtering may not be there...


3. Replay subscriptions (nice-to-have - for high-volume logging only)

   NSM's current logging protocol allows for the device to send logs
that
   may have been missed due to not being connected at the time the event
   occurred.  This is done by NSM telling the device, in its
subscription
   request, the timestamp of the last log it received and the device
doing
   its best effort to send that which was missed - this solution is only
   limited by the device's buffering capacity.

   All that said, NSM's configuration manager does NOT use this
mechanism
   to resynch its state as relying on the device's buffering capacity is
   fundamentally unreliable.  Thus, NSM's configuration manager always
   performs a diff to discover what has changed since its last
connection
   with the device.


4. Dynamic Subscriptions (must-have - for high-volume logging only)

   NSM's real-time monitor needs to modify its data subscription as=20
   users navigate around the UI to monitor different aspects of the=20
   device.  Please note that NSM may have multiple NSM client's looking
   at different aspects of the same device at the same time - regardless
   of the number of connected NSM clients, NSM always maintains just one
   connection to the device.  Without the ability to reliably replay
   notifications (see #3 above), re-connecting to the notification=20
   channel whenever modifying the subscription would potentially result
   in lost notifications and stale information being presented to the=20
   NSM client.


5. Notifications on same channel (nice-to-have)

   While I don't think this is architecturally critical, NSM's current
   proprietary configuration protocol does support notifications in the
   same channel as the RPCs - as I explained in my previous email, this
   was done because our configuration-manager component has its own=20
   logical connection to the device and it needs to both send RPCs and
   receive config-oriented notifications.  However, without too much
   effort, we could have architected each of our components to always
   have two channels (one for RPCs and the other for notifications) or
   have an adapter to multiplex the two device-channels into one channel
   inside our system.



BTW, its worth noting that NSM doesn't have any issues multiplexing=20
RPCs and notifications on the same channel since our protocol enables=20
messages to be fragmented and interleaved over-the-wire (each side=20
round-robins around their channel's send-queues).  This is where=20
NetConf fails - the issue has never been if notifications will get
blocked by large RPCs - it is that NetConf allows large RPCs and=20
they block everything!  NetConf's current "pipelined" nature inhibits
the ability for a management system to walk and chew gum on the same
channel.  While it may be more than this WG is ready to sign-up for,
I believe that we could fix this oversight via an "Asynchronous=20
Capability" that each side would need to advertise in its <hello>=20
enabling message-chunking - if there is sufficient interest, I could
draft a proposal for this...
  =20

Kent



--
Kent Watsen
NSM Architect
Juniper Networks


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



From owner-netconf@ops.ietf.org Mon Apr 03 16:37:02 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQVnK-0006Z9-F7
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 16:37:02 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQVnJ-0004SP-5c
	for netconf-archive@lists.ietf.org; Mon, 03 Apr 2006 16:37:02 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQVjH-000DIo-GT
	for netconf-data@psg.com; Mon, 03 Apr 2006 20:32: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 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 1FQVjG-000DIR-SA
	for netconf@ops.ietf.org; Mon, 03 Apr 2006 20:32:51 +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 k33KVDX93504;
	Mon, 3 Apr 2006 13:31:17 -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 k33KV7527436;
	Mon, 3 Apr 2006 13:31:07 -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 k33KaKYE088626;
	Mon, 3 Apr 2006 16:36:20 -0400 (EDT)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200604032036.k33KaKYE088626@idle.juniper.net>
To: Andy Bierman <ietf@andybierman.com>
cc: Sharon Chisholm <schishol@nortel.com>,
   "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: requirement: agent initiated session support 
In-Reply-To: Your message of "Mon, 03 Apr 2006 08:13:27 PDT."
             <44313B97.2050704@andybierman.com> 
Date: Mon, 03 Apr 2006 16:36:20 -0400
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352

Andy Bierman writes:
>>   <rpc>  <!-- from memory; check docs for accurate details -->
>>     <get-accounting-records>
>>       <since>YYYY-MM-DD.HH:MM:SS</since>
>>       <realtime/>
>>     </get-accounting-records>
>>   </rpc>
>I assume there are some config parameters
>to setup logging somewhere else.

Yup, I was going off memory, but there should be a <profile> element
containing the name of a pre-configured profile.  The profile's configuration
details the content and frequency for what's to be recorded.

>If <realtime/> is
>missing then the <rpc> finishes when all saved notifications
>have been delivered. If present, then the <rpc> never finishes,
>and (in this example) new notifications may be interleaved
>with saved notifications, so the manager needs to check the
>timestamp as usual.

Exactly.

>What about making it a generic RPC:
>
>  <rpc>
>    <get-log-records>
>       <type>accounting</type>    <!-- or syslog or whatever -->
>       <since>YYYY-MM-DD.HH:MM:SS</since>
>       <realtime/>
>    </get-log-records>
>  </rpc>

Even under type=syslog, you may need a syslog filename/collection name,
so the server can associate content with the name, as well as having 
somewhere to put aging 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 Apr 04 03:14:53 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQfkb-0001Sx-F8
	for netconf-archive@lists.ietf.org; Tue, 04 Apr 2006 03:14:53 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQfkY-0007LA-0F
	for netconf-archive@lists.ietf.org; Tue, 04 Apr 2006 03:14:53 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQfe9-0006SZ-9P
	for netconf-data@psg.com; Tue, 04 Apr 2006 07:08: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 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 1FQRHk-000ImM-AZ
	for netconf@ops.ietf.org; Mon, 03 Apr 2006 15:48:08 +0000
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k33FlvUb000540;
	Mon, 3 Apr 2006 08:47:57 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k33Flvor000536;
	Mon, 3 Apr 2006 08:47:57 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Mon, 3 Apr 2006 08:47:57 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Sharon Chisholm <schishol@nortel.com>
cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: RE: requirement: agent initiated session support
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B407AB940C@zcarhxm2.corp.nortel.com>
Message-ID: <Pine.LNX.4.10.10604030833550.23835-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: 244a2fd369eaf00ce6820a760a3de2e8

HI,

In addition to the points below, one must have "admin authorization"
to subscribe to receive notifications. Thus, I really believe
that there are two types of notification receivers -
1) those that run all the time and are primarily for storing
   a record of events for later analysis
2) those that are transient and are run when an application
   is changing the config or initiating and action

I believe that there is a need for both, and it seems like
the conflict has been over trying to choose either #1 or #2
instead of understanding the uses cases for each and making
it easy for each to be used where they are appropriate.

Enjoy,
/david t. perkins

On Mon, 3 Apr 2006, Sharon Chisholm wrote:
> <Andy>
> >> 2) get rid of all the parameters in the start-notifications
> >>    or modify-subscription except the profileName (index)
> >>
> >> This way agents and managers can both share the profiles
> >> and the manager won't reenter the same data in the most complex 
> >> manner possible every time.  I can configure the agent to connect to 
> >> notification receiver X using profile Y.  The manager can just 
> >> subscribe using profile Y.
> >>
> >> (An agent may not allow a profile in use to be modified.)
> </Andy>
> 
> As a manager who actually supported Notification subscription in SNMP, I
> hated the pre-configured approach for two reasons:
> 
> 1) It was way too complicated. It was spread out over 100 tables with
> far too many options. Even the case you used 99 times out of 100 was a
> lot of work. You would get it to work for some devices, then find one
> where it didn't work and realize that you forgot to create a row in yet
> another table. I like the idea of command-line options since it acts as
> a deterrent from over-engineering the subscription model
> 
> 2) It was persistent. I had to always check if I was already set up to
> get notifications from the box. This was more annoying then it sounds.
> 
> Plus, in a connection-oriented model, would we have the idea of
> subscriptions that were there, but not active for when the underlying
> session died?
> 
> 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/>
> 




--
to 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 Apr 04 03:15:03 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQfkl-0001Vr-7K
	for netconf-archive@lists.ietf.org; Tue, 04 Apr 2006 03:15:03 -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 1FQfkl-0007LN-5p
	for netconf-archive@lists.ietf.org; Tue, 04 Apr 2006 03:15:03 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FQfkj-0007aE-ET
	for netconf-archive@lists.ietf.org; Tue, 04 Apr 2006 03:15:03 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQfeH-0006T7-Pz
	for netconf-data@psg.com; Tue, 04 Apr 2006 07:08: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.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 1FQSjk-000Obk-D0
	for netconf@ops.ietf.org; Mon, 03 Apr 2006 17:21:08 +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 k33HGaq22611
	for <netconf@ops.ietf.org>; Mon, 3 Apr 2006 13:16: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: requirement: agent initiated session support
Date: Mon, 3 Apr 2006 13:21:04 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407B47B02@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: requirement: agent initiated session support
Thread-Index: AcZUsFQQCuI2QXEXTxmLUaUkE+BU+ACklZYg
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: -2.6 (--)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906


<Juergen>
Sure, with SNMPv3 you can in principle subscribe by configuring the
target tables but this (a) requires appropriate authorization rules and
(b) there is no standardized way to cleanup dynamic targets so crashing
apps leave garbage around which is painful to try to clean as well.

</Juergen>

I'm catching up on the mailing list in reverse order, but Juergen raises
some good points here. I forgot about the garbage collection issue.=20

Plus, I'm not sure I like the idea of other users being able to modify
my subscription.

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 Tue Apr 04 03:54:37 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQgN3-0006Ks-NB
	for netconf-archive@lists.ietf.org; Tue, 04 Apr 2006 03:54:37 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQgN3-0000X5-7d
	for netconf-archive@lists.ietf.org; Tue, 04 Apr 2006 03:54:37 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQgIH-000AQ4-8t
	for netconf-data@psg.com; Tue, 04 Apr 2006 07:49: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 [193.180.251.60] (helo=mailgw3.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FQgIF-000APk-KA
	for netconf@ops.ietf.org; Tue, 04 Apr 2006 07:49:39 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7F9FA4F0054
	for <netconf@ops.ietf.org>; Tue,  4 Apr 2006 09:49:38 +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, 4 Apr 2006 09:49:38 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 4 Apr 2006 09:49:37 +0200
Message-ID: <44322511.5050503@ericsson.com>
Date: Tue, 04 Apr 2006 09:49:37 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: requirement: agent initiated session support
References: <200604031452.k33EqZYE087783@idle.juniper.net>
In-Reply-To: <200604031452.k33EqZYE087783@idle.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Apr 2006 07:49:37.0981 (UTC) FILETIME=[52B6AED0:01C657BC]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64

I think having local copies is a good idea. We could think about the use case when the 
node is already running and the manager is switched on. This could follow a manager 
restart or a power outage where the agent comes up faster. The same could be useful if 
there is a trouble with the connection between the node and the manager.

In this case some notifications are lost anyway. It would be nice to be able to get these 
once the manager is up and running. This would naturally complicate the agent somewhat, so 
one has to decide if it is worth the effort.

Balazs


Phil Shafer wrote:
> Andy Bierman writes:
>> In the subscribe model, none of the agents can send any notifications
>> until a manager connects to them and asks for notifications.  The startup
>> notifications are critical to have, to check for any
>> config/image/HW mismatches that occurred during boot-up.
> 
> We do this with our accounting-profiles RPC (which I'm planning on
> mimicing for syslog data) with a combination of the <realtime/>
> flag and the <since>timestamp</since argument.  The system makes
> local copies of accounting records and can serve them up with a
> starting window, in realtime, or as a combination, where the records
> since the given timestamp are passed along and then the RPC switches
> to realtime.
> 
>   <rpc>  <!-- from memory; check docs for accurate details -->
>     <get-accounting-records>
>       <since>YYYY-MM-DD.HH:MM:SS</since>
>       <realtime/>
>     </get-accounting-records>
>   </rpc>
> 
> 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/>

-- 
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 Apr 04 08:24:40 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQkaO-0007l9-HZ
	for netconf-archive@lists.ietf.org; Tue, 04 Apr 2006 08:24:40 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQkaL-0002vT-W8
	for netconf-archive@lists.ietf.org; Tue, 04 Apr 2006 08:24:40 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQkJI-0006FE-0h
	for netconf-data@psg.com; Tue, 04 Apr 2006 12:07: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.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.78] (helo=test-iport-3.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <lear@cisco.com>)
	id 1FQfuo-0007yx-Ap
	for netconf@ops.ietf.org; Tue, 04 Apr 2006 07:25:26 +0000
Received: from sj-core-2.cisco.com ([171.71.177.254])
  by test-iport-3.cisco.com with ESMTP; 04 Apr 2006 00:25:26 -0700
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k347PPGv007245;
	Tue, 4 Apr 2006 00:25:25 -0700 (PDT)
Received: from [212.254.247.5] (ams3-vpn-dhcp4298.cisco.com [10.61.80.201])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k347PZ7W022877;
	Tue, 4 Apr 2006 00:25:35 -0700
Message-ID: <44321F63.5090207@cisco.com>
Date: Tue, 04 Apr 2006 09:25:23 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: "David T. Perkins" <dperkins@dsperkins.com>
CC: Sharon Chisholm <schishol@nortel.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: requirement: agent initiated session support
References: <Pine.LNX.4.10.10604030833550.23835-100000@shell4.bayarea.net>
In-Reply-To: <Pine.LNX.4.10.10604030833550.23835-100000@shell4.bayarea.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=555; t=1144135536; x=1144999536;
	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=20requirement=3A=20agent=20initiated=20session=20support
	|To:=22David=20T.=20Perkins=22=20<dperkins@dsperkins.com>;
	X=v=3Dcisco.com=3B=20h=3DGJT6GFqBS+nA6G7z8bAuIzN0dJs=3D; b=jInncDrlp8lnmxs9qunXbrufCjkvs6F5pJZGMjX4G1jR4/rwZYvRf3p7DY7zbMDCB0dKQRqW
	Z70Dvu/8xTo/qosKj7beUQ4twbor+nidgTXkPPv1beyuMKqNrGiVH9y7;
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: 93238566e09e6e262849b4f805833007

David T. Perkins wrote:
> HI,
>
> In addition to the points below, one must have "admin authorization"
> to subscribe to receive notifications. Thus, I really believe
> that there are two types of notification receivers -
> 1) those that run all the time and are primarily for storing
>    a record of events for later analysis
> 2) those that are transient and are run when an application
>    is changing the config or initiating and action
>   

How about:

  3) Those that run all the time and keep track of inventory changes?

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 Tue Apr 04 11:28:34 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQnSM-0002id-EU
	for netconf-archive@lists.ietf.org; Tue, 04 Apr 2006 11:28:34 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQnSL-0003Ey-Vn
	for netconf-archive@lists.ietf.org; Tue, 04 Apr 2006 11:28:34 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQnLQ-000O76-KL
	for netconf-data@psg.com; Tue, 04 Apr 2006 15:21: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.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1
Received: from [62.241.163.6] (helo=astro.systems.pipex.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <nwnetworks@dial.pipex.com>)
	id 1FQnLP-000O6n-Jg
	for netconf@ops.ietf.org; Tue, 04 Apr 2006 15:21:23 +0000
Received: from pc6 (1Cust232.tnt3.lnd4.gbr.da.uu.net [62.188.132.232])
	by astro.systems.pipex.net (Postfix) with SMTP id 76DE6E0002F5;
	Tue,  4 Apr 2006 16:21:14 +0100 (BST)
Message-ID: <022601c657f2$bdd9af60$0601a8c0@pc6>
Reply-To: "Tom Petch" <nwnetworks@dial.pipex.com>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
Cc: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0A43C381@is0004avexu1.global.avaya.com>
Subject: Re: real problem? was Re: no interim meeting -- read the rules
Date: Tue, 4 Apr 2006 16:15:48 +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: a7d6aff76b15f3f56fcb94490e1052e4

----- Original Message -----
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Tom Petch" <nwnetworks@dial.pipex.com>; "Balazs Lengyel"
<balazs.lengyel@ericsson.com>; "Andy Bierman" <ietf@andybierman.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Sent: Thursday, March 30, 2006 3:15 PM
Subject: RE: real problem? was Re: no interim meeting -- read the rules

> -----Original Message-----
>> We have to care about a second transport/security mechanism TLS (I don't know
if this is a real problem).
>
> Yes, I suspect it is.  In a secure, distributed system,
> particularly one with a large number of unattended boxes, I
> believe that the distribution and maintenance of security
> credentials is a real problem, much complexity and expense.
>
> So (netconf over) ssh for configuration with the necessary
> notifications coming back (over syslog) over tls.  I don't
> know anyone doing security that way so I imagine it is
> significantly  more complex than just ssh or tls (or ipsec or
> ....).  Anyone know otherwise?
>

What exactly are the security credentials for?
<>
Security credentials are used for authentication (and perhaps key exchange) and
so include certificates, public/private key pairs, pre-shared keys etc.

The work involved in the distribution of such material is perceived to be an
inhibitor to the take up of SNMPv3:-(

Tom Petch
<snip>

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 Tue Apr 04 11:35:48 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQnZM-0006BA-MT
	for netconf-archive@lists.ietf.org; Tue, 04 Apr 2006 11:35:48 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FQnZM-0003ct-4z
	for netconf-archive@lists.ietf.org; Tue, 04 Apr 2006 11:35:48 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FQnV7-000POW-6W
	for netconf-data@psg.com; Tue, 04 Apr 2006 15:31: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.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 1FQnV5-000POA-U8
	for netconf@ops.ietf.org; Tue, 04 Apr 2006 15:31:24 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k34FVLts030226
	for <netconf@ops.ietf.org>; Tue, 4 Apr 2006 11:31:22 -0400
Received: (qmail 4294 invoked by uid 78); 4 Apr 2006 15:31:21 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.113 with SMTP; 4 Apr 2006 15:31:21 -0000
Message-ID: <44329142.6060708@andybierman.com>
Date: Tue, 04 Apr 2006 08:31:14 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: requirement: agent initiated session support
References: <200604031452.k33EqZYE087783@idle.juniper.net> <44322511.5050503@ericsson.com>
In-Reply-To: <44322511.5050503@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: 386e0819b1192672467565a524848168

Balazs Lengyel wrote:
> I think having local copies is a good idea. We could think about the use 
> case when the node is already running and the manager is switched on. 
> This could follow a manager restart or a power outage where the agent 
> comes up faster. The same could be useful if there is a trouble with the 
> connection between the node and the manager.
> 
> In this case some notifications are lost anyway. It would be nice to be 
> able to get these once the manager is up and running. This would 
> naturally complicate the agent somewhat, so one has to decide if it is 
> worth the effort.

Worth the effort... hmmm...

First, there will be different size ring buffers on each agent.
The manager will not have as long as it wants to get all the
startup notifications.  It won't know how long it has
to finish hunting down all the agents and retrieving
their notifications (this sounds a lot more like
dumb polling that notification-driven NM.)

IMO, this is clearly a way to add more complexity to
deal with an already inappropriately complex design.
Just keep piling on complexity until you get it to work.

I don't think the "manager-subscribe" model is appropriate
for general notification management at all.  It is somewhat
convenient (in some contrived cases) for a manager to receive
the supposedly related notifications immediately following an
RPC operation on the same session.  This is only true if the
NMS has no need to centrally process notifications at all.

I would like to know if there are any products used by operators
that manage notifications with a client-subscribe, client-provides
all parameters architecture.  I doubt it.  Even the publish/subscribe
models use SW and NV-config on the agent so it knows what events to
publish.

Are there Cisco or Nortel products that work as described
in the Notifications draft?  If so, how do operators use
it and in what kind of relative numbers (compared to more
traditional notification approaches).



> 
> Balazs


Andy

> 
> 
> Phil Shafer wrote:
>> Andy Bierman writes:
>>> In the subscribe model, none of the agents can send any notifications
>>> until a manager connects to them and asks for notifications.  The 
>>> startup
>>> notifications are critical to have, to check for any
>>> config/image/HW mismatches that occurred during boot-up.
>>
>> We do this with our accounting-profiles RPC (which I'm planning on
>> mimicing for syslog data) with a combination of the <realtime/>
>> flag and the <since>timestamp</since argument.  The system makes
>> local copies of accounting records and can serve them up with a
>> starting window, in realtime, or as a combination, where the records
>> since the given timestamp are passed along and then the RPC switches
>> to realtime.
>>
>>   <rpc>  <!-- from memory; check docs for accurate details -->
>>     <get-accounting-records>
>>       <since>YYYY-MM-DD.HH:MM:SS</since>
>>       <realtime/>
>>     </get-accounting-records>
>>   </rpc>
>>
>> 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 Wed Apr 05 03:05:28 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FR24O-0003pA-0q
	for netconf-archive@lists.ietf.org; Wed, 05 Apr 2006 03:04:48 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FR1yy-0007cQ-JV
	for netconf-archive@lists.ietf.org; Wed, 05 Apr 2006 02:59:14 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FR1t7-0005ZM-8X
	for netconf-data@psg.com; Wed, 05 Apr 2006 06:53: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,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 1FR1t5-0005Z9-6J
	for netconf@ops.ietf.org; Wed, 05 Apr 2006 06:53:07 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 028B24F0001;
	Wed,  5 Apr 2006 08:53:06 +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, 5 Apr 2006 08:53:05 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 5 Apr 2006 08:53:05 +0200
Message-ID: <44336951.5010207@ericsson.com>
Date: Wed, 05 Apr 2006 08:53:05 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: requirement: agent initiated session support
References: <200604031452.k33EqZYE087783@idle.juniper.net> <44322511.5050503@ericsson.com> <44329142.6060708@andybierman.com>
In-Reply-To: <44329142.6060708@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Apr 2006 06:53:05.0636 (UTC) FILETIME=[9721AA40:01C6587D]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e

I see the replay capability as an independent topic from subscription based notifications.

Also for us one use case is managing a relatively small number < 50 of big nodes where we 
do not want to loose any notifications. In this case replay is really useful. We already 
have it in an SNMP based system.

Still when managing hundreds or thousands of nodes replay might not be as useful.
If you object to replay I can live without it.

Balazs

Andy Bierman wrote:
> Balazs Lengyel wrote:
>> I think having local copies is a good idea. We could think about the 
>> use case when the node is already running and the manager is switched 
>> on. This could follow a manager restart or a power outage where the 
>> agent comes up faster. The same could be useful if there is a trouble 
>> with the connection between the node and the manager.
>>
>> In this case some notifications are lost anyway. It would be nice to 
>> be able to get these once the manager is up and running. This would 
>> naturally complicate the agent somewhat, so one has to decide if it is 
>> worth the effort.
> 
> Worth the effort... hmmm...
> 
> First, there will be different size ring buffers on each agent.
> The manager will not have as long as it wants to get all the
> startup notifications.  It won't know how long it has
> to finish hunting down all the agents and retrieving
> their notifications (this sounds a lot more like
> dumb polling that notification-driven NM.)
> 
> IMO, this is clearly a way to add more complexity to
> deal with an already inappropriately complex design.
> Just keep piling on complexity until you get it to work.
> 
> I don't think the "manager-subscribe" model is appropriate
> for general notification management at all.  It is somewhat
> convenient (in some contrived cases) for a manager to receive
> the supposedly related notifications immediately following an
> RPC operation on the same session.  This is only true if the
> NMS has no need to centrally process notifications at all.
> 
> I would like to know if there are any products used by operators
> that manage notifications with a client-subscribe, client-provides
> all parameters architecture.  I doubt it.  Even the publish/subscribe
> models use SW and NV-config on the agent so it knows what events to
> publish.
> 
> Are there Cisco or Nortel products that work as described
> in the Notifications draft?  If so, how do operators use
> it and in what kind of relative numbers (compared to more
> traditional notification approaches).
> 
> 
> 
>>
>> Balazs
> 
> 
> Andy
> 
>>
>>
>> Phil Shafer wrote:
>>> Andy Bierman writes:
>>>> In the subscribe model, none of the agents can send any notifications
>>>> until a manager connects to them and asks for notifications.  The 
>>>> startup
>>>> notifications are critical to have, to check for any
>>>> config/image/HW mismatches that occurred during boot-up.
>>>
>>> We do this with our accounting-profiles RPC (which I'm planning on
>>> mimicing for syslog data) with a combination of the <realtime/>
>>> flag and the <since>timestamp</since argument.  The system makes
>>> local copies of accounting records and can serve them up with a
>>> starting window, in realtime, or as a combination, where the records
>>> since the given timestamp are passed along and then the RPC switches
>>> to realtime.
>>>
>>>   <rpc>  <!-- from memory; check docs for accurate details -->
>>>     <get-accounting-records>
>>>       <since>YYYY-MM-DD.HH:MM:SS</since>
>>>       <realtime/>
>>>     </get-accounting-records>
>>>   </rpc>
>>>
>>> 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/>
>>
> 

-- 
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 Apr 05 15:50:57 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FRE1p-0001Bx-5J
	for netconf-archive@lists.ietf.org; Wed, 05 Apr 2006 15:50:57 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FRE1n-0007Vg-Lu
	for netconf-archive@lists.ietf.org; Wed, 05 Apr 2006 15:50:57 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FRDvX-0003gP-Pn
	for netconf-data@psg.com; Wed, 05 Apr 2006 19:44: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.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 1FRDvW-0003gB-Ms
	for netconf@ops.ietf.org; Wed, 05 Apr 2006 19:44:26 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k35JiPHx002714
	for <netconf@ops.ietf.org>; Wed, 5 Apr 2006 15:44:25 -0400
Received: (qmail 21566 invoked by uid 78); 5 Apr 2006 19:44:25 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.113 with SMTP; 5 Apr 2006 19:44:25 -0000
Message-ID: <44341DF1.3060900@andybierman.com>
Date: Wed, 05 Apr 2006 12:43:45 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: NETCONF WG Interim Meeting Announcement
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: bb8f917bb6b8da28fc948aeffb74aa17

Hi,

The IESG approved my request for an interim meeting in Montreal.
We will request a Friday morning 9-11:30 slot, and then have
an interim meeting on Friday afternoon and all day Saturday.
I hope you plan to attend all week.  Montreal is a beautiful
city and there are lots of other WGs you should be following
besides NETCONF.


Location:     Montreal, Canada at the IETF 66 hotel (TBD)

Dates/Times:  Friday, July 14, 2006
               1:30 - 3:30 PM
               4:00 - 6:00 PM

               Saturday, July 15, 2006
               9:00 - 11:30 AM
               1:30 -  3:30 PM
               4:00 -  6:00 PM

Sponsors:     TBD - looking for sponsors to help pay for room (for 20),
               whiteboard, and screen.  Also looking for a
               loaner video projector for the meeting.

Agenda:       NETCONF Event Notifications

Wifi Net:     none



--
to 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 Apr 05 17:45:41 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FRFor-0001hU-1K
	for netconf-archive@lists.ietf.org; Wed, 05 Apr 2006 17:45:41 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FRFoq-00072H-N4
	for netconf-archive@lists.ietf.org; Wed, 05 Apr 2006 17:45:41 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FRFhs-000EeL-CO
	for netconf-data@psg.com; Wed, 05 Apr 2006 21:38: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 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 1FRFhr-000Ee6-Fk
	for netconf@ops.ietf.org; Wed, 05 Apr 2006 21:38:27 +0000
Received: from tierw.net.avaya.com (h198-152-13-100.avaya.com [198.152.13.100])
	by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k35LatGp018097
	for <netconf@ops.ietf.org>; Wed, 5 Apr 2006 17:36:56 -0400
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by tierw.net.avaya.com (Switch-3.1.8/Switch-3.1.0) with ESMTP id k35LM8mk002245
	for <netconf@ops.ietf.org>; Wed, 5 Apr 2006 17:22:08 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: NETCONF WG Interim Meeting Announcement
Date: Thu, 6 Apr 2006 00:38:24 +0300
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A4DE7C9@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: NETCONF WG Interim Meeting Announcement
Thread-Index: AcZY6avyzF1MzibNRI2NlJHY1t0MxgADm90g
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: f60d0f7806b0c40781eee6b9cd0b2135

To be more accurate - the AD approved.=20

The IESG made the point that such a scheduling for an interim is rather
an exception made at the request of the WG, in the interest of making
progress for the chartered items while minimizing travel expenses for
the participants, and should not be considered a precedent. As Andy
wrote, the NETCONF participants are encouraged to take active part in
other IETF activities during the week.

I would recommend that the chairs do a headcount of the potential
participants, so that you are not surprised by the numbers. 20 may be a
low number, I remember higher number in Dallas. =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: Wednesday, April 05, 2006 10:44 PM
> To: Netconf (E-mail)
> Subject: NETCONF WG Interim Meeting Announcement
>=20
> Hi,
>=20
> The IESG approved my request for an interim meeting in Montreal.
> We will request a Friday morning 9-11:30 slot, and then have=20
> an interim meeting on Friday afternoon and all day Saturday.
> I hope you plan to attend all week.  Montreal is a beautiful=20
> city and there are lots of other WGs you should be following=20
> besides NETCONF.
>=20
>=20
> Location:     Montreal, Canada at the IETF 66 hotel (TBD)
>=20
> Dates/Times:  Friday, July 14, 2006
>                1:30 - 3:30 PM
>                4:00 - 6:00 PM
>=20
>                Saturday, July 15, 2006
>                9:00 - 11:30 AM
>                1:30 -  3:30 PM
>                4:00 -  6:00 PM
>=20
> Sponsors:     TBD - looking for sponsors to help pay for room=20
> (for 20),
>                whiteboard, and screen.  Also looking for a
>                loaner video projector for the meeting.
>=20
> Agenda:       NETCONF Event Notifications
>=20
> Wifi Net:     none
>=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 Thu Apr 06 11:30:35 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FRWRP-0007i1-7R
	for netconf-archive@lists.ietf.org; Thu, 06 Apr 2006 11:30:35 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FRWRM-0004Nf-TN
	for netconf-archive@lists.ietf.org; Thu, 06 Apr 2006 11:30:35 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FRWId-0000KZ-OF
	for netconf-data@psg.com; Thu, 06 Apr 2006 15:21: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=ns-omrbm4.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FRWId-0000KJ-2w
	for netconf@ops.ietf.org; Thu, 06 Apr 2006 15:21:31 +0000
Received: from mail.networksolutionsemail.com (omr4.mgt.bos.netsol.com [10.49.2.114] (may be forged))
	by ns-omrbm4.netsolmail.com (8.12.10/8.12.10) with SMTP id k36FLTQ3025691
	for <netconf@ops.ietf.org>; Thu, 6 Apr 2006 11:21:30 -0400
Received: (qmail 22309 invoked by uid 78); 6 Apr 2006 15:21:29 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.114 with SMTP; 6 Apr 2006 15:21:29 -0000
Message-ID: <443531F3.7000903@andybierman.com>
Date: Thu, 06 Apr 2006 08:21:23 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: architecture and security
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: 0ddefe323dd869ab027dbfff7eff0465

Hi,

I think the architecture for netconf notifications needs more attention.
The current draft tries to fit notifications into the existing model
for remote procedure calls.  The <rpc-one-way> is supposedly just
like a regular <rpc>, except it goes from the agent to the manager,
and there is no return value.  Also, the WG decided (based on
Junoscript experience) that returning <ok> was better than
no return value -- we explicitly don't want a 1-way-rpc --
in either direction.


There are 2 major problems with this architecture:

1) Headers are different becase the messages are different;
   Notifications have different general characteristics
   than RPC requests, so the headers will be different
   (e.g., no timestamp in an RPC request like a notification)

2) Access control is backwards;
   It doesn't make sense to apply access control to the '1 way RPC'
   in the same sense as a regular RPC.  It is the manager who is
   supposed to have access granted to view specific agent data -- not
   the agent that is supposed to have access granted to
   send the manager specific agent data.


Even though the term <rpc-one-way> is being removed, and the
message will be called <notification> instead (as it is on
page 17), we still need a secure architecture which scales well,
and will support a user-based access control model.
We need to think of how notifications fit into the base
netconf protocol, as well as existing security and NM protocols.
Operational issues and common use cases (e.g., building power-cycle)
need to be addressed.

Once the requirements and architecture are understood,
we will be able to simplify and focus the API.  It isn't
acceptable to come to the conclusion that a feature is
a 95% lose-lose scenario, but we should do it anyway.


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 Apr 06 15:06:30 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FRZoM-0006kk-9X
	for netconf-archive@lists.ietf.org; Thu, 06 Apr 2006 15:06:30 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FRZoL-0003Wx-V8
	for netconf-archive@lists.ietf.org; Thu, 06 Apr 2006 15:06:30 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FRZib-000Fm1-5J
	for netconf-data@psg.com; Thu, 06 Apr 2006 19:00:33 +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.120] (helo=kremlin.juniper.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <kwatsen@juniper.net>)
	id 1FRZia-000Flm-Ck
	for netconf@ops.ietf.org; Thu, 06 Apr 2006 19:00:32 +0000
Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25])
  by kremlin.juniper.net with ESMTP; 06 Apr 2006 12:00:32 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.04,93,1144047600"; 
   d="scan'208"; a="538242141:sNHT34401052"
Received: from antitop.jnpr.net ([172.24.15.27]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 6 Apr 2006 12:00:31 -0700
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: architecture and security
Date: Thu, 6 Apr 2006 12:00:28 -0700
Message-ID: <B8C821F9E0675D44BFA994C28C0120E5E2507B@antitop.jnpr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: architecture and security
Thread-Index: AcZZjieOJiyYsA2RSqCAVXhV5q2mkAAEl55Q
From: "Kent Watsen" <kwatsen@juniper.net>
To: "Andy Bierman" <ietf@andybierman.com>,
	"Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 06 Apr 2006 19:00:31.0612 (UTC) FILETIME=[6092D3C0:01C659AC]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43


NSM also supports notifications thru its northbound interface.  The way
that we address access control is by authorizing the subscription
request.  This approach has proven ideal for us as it:

  1. limits the system to only having to test client-initiated requests
  2. enables the system to add "implicit-filters" to the requests
  3. eliminates the system from having to apply filters to the responses

To understand the desire for implicit filters, please consider that the
system may implement granular access-controls such that an authenticated
user may only have access to a subset of a data repository.  For
instance, the user may only have access to a particular virtual system
(i.e. virtual router); from the user's perspective, the subscription
might be to "all events" but, upon receiving the request, the system's
access-control module might add an implicit-filter so that the request
then reads "all events where event->vsys =3D=3D user->vsys" - after =
having
modified the incoming request, the access-control module can than pass
the request down into the system, which can remain unaware of
access-control issues...


Kent





-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Thursday, April 06, 2006 8:21 AM
To: Netconf (E-mail)
Subject: architecture and security

Hi,

I think the architecture for netconf notifications needs more attention.
The current draft tries to fit notifications into the existing model
for remote procedure calls.  The <rpc-one-way> is supposedly just
like a regular <rpc>, except it goes from the agent to the manager,
and there is no return value.  Also, the WG decided (based on
Junoscript experience) that returning <ok> was better than
no return value -- we explicitly don't want a 1-way-rpc --
in either direction.


There are 2 major problems with this architecture:

1) Headers are different becase the messages are different;
   Notifications have different general characteristics
   than RPC requests, so the headers will be different
   (e.g., no timestamp in an RPC request like a notification)

2) Access control is backwards;
   It doesn't make sense to apply access control to the '1 way RPC'
   in the same sense as a regular RPC.  It is the manager who is
   supposed to have access granted to view specific agent data -- not
   the agent that is supposed to have access granted to
   send the manager specific agent data.


Even though the term <rpc-one-way> is being removed, and the
message will be called <notification> instead (as it is on
page 17), we still need a secure architecture which scales well,
and will support a user-based access control model.
We need to think of how notifications fit into the base
netconf protocol, as well as existing security and NM protocols.
Operational issues and common use cases (e.g., building power-cycle)
need to be addressed.

Once the requirements and architecture are understood,
we will be able to simplify and focus the API.  It isn't
acceptable to come to the conclusion that a feature is
a 95% lose-lose scenario, but we should do it anyway.


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 Thu Apr 06 16:00:21 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FRaeT-0001Je-V1
	for netconf-archive@lists.ietf.org; Thu, 06 Apr 2006 16:00:21 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FRaeT-0005TO-EI
	for netconf-archive@lists.ietf.org; Thu, 06 Apr 2006 16:00:21 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FRaXB-000J6t-Nj
	for netconf-data@psg.com; Thu, 06 Apr 2006 19:52: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 1FRaXA-000J6i-ET
	for netconf@ops.ietf.org; Thu, 06 Apr 2006 19:52:48 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k36JqkHx008004
	for <netconf@ops.ietf.org>; Thu, 6 Apr 2006 15:52:47 -0400
Received: (qmail 29749 invoked by uid 78); 6 Apr 2006 19:52:46 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.113 with SMTP; 6 Apr 2006 19:52:46 -0000
Message-ID: <44357188.9030004@andybierman.com>
Date: Thu, 06 Apr 2006 12:52:40 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Kent Watsen <kwatsen@juniper.net>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: architecture and security
References: <B8C821F9E0675D44BFA994C28C0120E5E2507B@antitop.jnpr.net>
In-Reply-To: <B8C821F9E0675D44BFA994C28C0120E5E2507B@antitop.jnpr.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: b1c41982e167b872076d0018e4e1dc3c

Kent Watsen wrote:
> NSM also supports notifications thru its northbound interface.  The way
> that we address access control is by authorizing the subscription
> request.  This approach has proven ideal for us as it:
> 
>   1. limits the system to only having to test client-initiated requests
>   2. enables the system to add "implicit-filters" to the requests
>   3. eliminates the system from having to apply filters to the responses
> 
> To understand the desire for implicit filters, please consider that the
> system may implement granular access-controls such that an authenticated
> user may only have access to a subset of a data repository.  For
> instance, the user may only have access to a particular virtual system
> (i.e. virtual router); from the user's perspective, the subscription
> might be to "all events" but, upon receiving the request, the system's
> access-control module might add an implicit-filter so that the request
> then reads "all events where event->vsys == user->vsys" - after having
> modified the incoming request, the access-control module can than pass
> the request down into the system, which can remain unaware of
> access-control issues...

I need to understand this architecture better.
The WG agreed that a user-based access control model
needs to be supported, but we never specified the details.


So "user A" connects to your NB NSM API to receive notifications.

The NSM (as "user B") has a SB session to a netconf agent configured
to send notifications.

Then "user C" connects to the netconf agent and causes a notification
to be generated.

Let's use the (unexplained) example in sec. 5.1 of the draft.

The agent knows that user C has access to this <config> data.
How does the agent know that the information in the <data> element,
such as the operation performed, the interface name, or the mtu,
can be viewed by user B?  How does the your NSM make sure that
user A has proper access to this data?

I think the netconf standard architecture needs to account
for the user C -> B scenario, but avoid proxy in the model
at all costs (i.e., leave C -> B -> A out of the model).
I think the access control granularity needs to be per-object
at least, and per-instance in some use cases.



> 
> 
> Kent
> 

Andy


> 
> 
> 
> 
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
> Behalf Of Andy Bierman
> Sent: Thursday, April 06, 2006 8:21 AM
> To: Netconf (E-mail)
> Subject: architecture and security
> 
> Hi,
> 
> I think the architecture for netconf notifications needs more attention.
> The current draft tries to fit notifications into the existing model
> for remote procedure calls.  The <rpc-one-way> is supposedly just
> like a regular <rpc>, except it goes from the agent to the manager,
> and there is no return value.  Also, the WG decided (based on
> Junoscript experience) that returning <ok> was better than
> no return value -- we explicitly don't want a 1-way-rpc --
> in either direction.
> 
> 
> There are 2 major problems with this architecture:
> 
> 1) Headers are different becase the messages are different;
>    Notifications have different general characteristics
>    than RPC requests, so the headers will be different
>    (e.g., no timestamp in an RPC request like a notification)
> 
> 2) Access control is backwards;
>    It doesn't make sense to apply access control to the '1 way RPC'
>    in the same sense as a regular RPC.  It is the manager who is
>    supposed to have access granted to view specific agent data -- not
>    the agent that is supposed to have access granted to
>    send the manager specific agent data.
> 
> 
> Even though the term <rpc-one-way> is being removed, and the
> message will be called <notification> instead (as it is on
> page 17), we still need a secure architecture which scales well,
> and will support a user-based access control model.
> We need to think of how notifications fit into the base
> netconf protocol, as well as existing security and NM protocols.
> Operational issues and common use cases (e.g., building power-cycle)
> need to be addressed.
> 
> Once the requirements and architecture are understood,
> we will be able to simplify and focus the API.  It isn't
> acceptable to come to the conclusion that a feature is
> a 95% lose-lose scenario, but we should do it anyway.
> 
> 
> 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 Apr 06 17:54:12 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FRcQe-0003h8-Sx
	for netconf-archive@lists.ietf.org; Thu, 06 Apr 2006 17:54:12 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FRcQe-0000Q2-EP
	for netconf-archive@lists.ietf.org; Thu, 06 Apr 2006 17:54:12 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FRcKW-00009S-6y
	for netconf-data@psg.com; Thu, 06 Apr 2006 21:47: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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [207.17.137.119] (helo=borg.juniper.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <kwatsen@juniper.net>)
	id 1FRcKV-00009D-5K
	for netconf@ops.ietf.org; Thu, 06 Apr 2006 21:47:51 +0000
Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109])
  by borg.juniper.net with ESMTP; 06 Apr 2006 14:47:50 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.04,94,1144047600"; 
   d="scan'208"; a="541507758:sNHT35930272"
Received: from antitop.jnpr.net ([172.24.15.27]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 6 Apr 2006 14:47:50 -0700
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: architecture and security
Date: Thu, 6 Apr 2006 14:47:49 -0700
Message-ID: <B8C821F9E0675D44BFA994C28C0120E5E25083@antitop.jnpr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: architecture and security
Thread-Index: AcZZs7fwRe18Ic3NT96E41rv4+X7LwADo3ig
From: "Kent Watsen" <kwatsen@juniper.net>
To: "Andy Bierman" <ietf@andybierman.com>
Cc: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 06 Apr 2006 21:47:50.0188 (UTC) FILETIME=[C007F6C0:01C659C3]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 225414c974e0d6437992164e91287a51


Yikes - there is slight misunderstanding; I was using NSM's NB API by
example - since we have already solved this problem.  I am in no way
trying to suggest or advocate a proxy from NSM's client to the device.

I was addressing your "Access control is backwards" concern by
explaining that it is a non-issue as the device only needs to auth the
initial subscription request - any matching events the device generates
are implicitly authorized to go to all subscribers of that event.  Thus,
all access-control is still "forwards"

Kent



-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]=20
Sent: Thursday, April 06, 2006 12:53 PM
To: Kent Watsen
Cc: Netconf (E-mail)
Subject: Re: architecture and security

Kent Watsen wrote:
> NSM also supports notifications thru its northbound interface.  The
way
> that we address access control is by authorizing the subscription
> request.  This approach has proven ideal for us as it:
>=20
>   1. limits the system to only having to test client-initiated
requests
>   2. enables the system to add "implicit-filters" to the requests
>   3. eliminates the system from having to apply filters to the
responses
>=20
> To understand the desire for implicit filters, please consider that
the
> system may implement granular access-controls such that an
authenticated
> user may only have access to a subset of a data repository.  For
> instance, the user may only have access to a particular virtual system
> (i.e. virtual router); from the user's perspective, the subscription
> might be to "all events" but, upon receiving the request, the system's
> access-control module might add an implicit-filter so that the request
> then reads "all events where event->vsys =3D=3D user->vsys" - after =
having
> modified the incoming request, the access-control module can than pass
> the request down into the system, which can remain unaware of
> access-control issues...

I need to understand this architecture better.
The WG agreed that a user-based access control model
needs to be supported, but we never specified the details.


So "user A" connects to your NB NSM API to receive notifications.

The NSM (as "user B") has a SB session to a netconf agent configured
to send notifications.

Then "user C" connects to the netconf agent and causes a notification
to be generated.

Let's use the (unexplained) example in sec. 5.1 of the draft.

The agent knows that user C has access to this <config> data.
How does the agent know that the information in the <data> element,
such as the operation performed, the interface name, or the mtu,
can be viewed by user B?  How does the your NSM make sure that
user A has proper access to this data?

I think the netconf standard architecture needs to account
for the user C -> B scenario, but avoid proxy in the model
at all costs (i.e., leave C -> B -> A out of the model).
I think the access control granularity needs to be per-object
at least, and per-instance in some use cases.



>=20
>=20
> Kent
>=20

Andy


>=20
>=20
>=20
>=20
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
On
> Behalf Of Andy Bierman
> Sent: Thursday, April 06, 2006 8:21 AM
> To: Netconf (E-mail)
> Subject: architecture and security
>=20
> Hi,
>=20
> I think the architecture for netconf notifications needs more
attention.
> The current draft tries to fit notifications into the existing model
> for remote procedure calls.  The <rpc-one-way> is supposedly just
> like a regular <rpc>, except it goes from the agent to the manager,
> and there is no return value.  Also, the WG decided (based on
> Junoscript experience) that returning <ok> was better than
> no return value -- we explicitly don't want a 1-way-rpc --
> in either direction.
>=20
>=20
> There are 2 major problems with this architecture:
>=20
> 1) Headers are different becase the messages are different;
>    Notifications have different general characteristics
>    than RPC requests, so the headers will be different
>    (e.g., no timestamp in an RPC request like a notification)
>=20
> 2) Access control is backwards;
>    It doesn't make sense to apply access control to the '1 way RPC'
>    in the same sense as a regular RPC.  It is the manager who is
>    supposed to have access granted to view specific agent data -- not
>    the agent that is supposed to have access granted to
>    send the manager specific agent data.
>=20
>=20
> Even though the term <rpc-one-way> is being removed, and the
> message will be called <notification> instead (as it is on
> page 17), we still need a secure architecture which scales well,
> and will support a user-based access control model.
> We need to think of how notifications fit into the base
> netconf protocol, as well as existing security and NM protocols.
> Operational issues and common use cases (e.g., building power-cycle)
> need to be addressed.
>=20
> Once the requirements and architecture are understood,
> we will be able to simplify and focus the API.  It isn't
> acceptable to come to the conclusion that a feature is
> a 95% lose-lose scenario, but we should do it anyway.
>=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
> --
> to 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 Thu Apr 06 18:22:56 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FRcsS-0007ms-Gj
	for netconf-archive@lists.ietf.org; Thu, 06 Apr 2006 18:22:56 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FRcsS-0001Dr-1M
	for netconf-archive@lists.ietf.org; Thu, 06 Apr 2006 18:22:56 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FRcmn-00025E-Rg
	for netconf-data@psg.com; Thu, 06 Apr 2006 22:17: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.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FRcmm-00024U-Ff
	for netconf@ops.ietf.org; Thu, 06 Apr 2006 22:17:04 +0000
Received: from mail.networksolutionsemail.com (omr5.mgt.bos.netsol.com [10.49.2.115] (may be forged))
	by ns-omrbm5.netsolmail.com (8.12.10/8.12.10) with SMTP id k36MH24F006372
	for <netconf@ops.ietf.org>; Thu, 6 Apr 2006 18:17:03 -0400
Received: (qmail 20943 invoked by uid 78); 6 Apr 2006 22:17:02 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.115 with SMTP; 6 Apr 2006 22:17:02 -0000
Message-ID: <44359358.2070908@andybierman.com>
Date: Thu, 06 Apr 2006 15:16:56 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Kent Watsen <kwatsen@juniper.net>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: architecture and security
References: <B8C821F9E0675D44BFA994C28C0120E5E25083@antitop.jnpr.net>
In-Reply-To: <B8C821F9E0675D44BFA994C28C0120E5E25083@antitop.jnpr.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: 0e9ebc0cbd700a87c0637ad0e2c91610

Kent Watsen wrote:
> Yikes - there is slight misunderstanding; I was using NSM's NB API by
> example - since we have already solved this problem.  I am in no way
> trying to suggest or advocate a proxy from NSM's client to the device.
> 
> I was addressing your "Access control is backwards" concern by
> explaining that it is a non-issue as the device only needs to auth the
> initial subscription request - any matching events the device generates
> are implicitly authorized to go to all subscribers of that event.  Thus,
> all access-control is still "forwards"

So the agent has to check the filters to see if they can ever
match a data model that the subscriber is not allowed to see,
and reject the subscription request with an access-denied error.

Or does the agent silently omit notifications which don't resolve
to access-granted for that receiver?

> 
> Kent

Andy

> 
> 
> 
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com] 
> Sent: Thursday, April 06, 2006 12:53 PM
> To: Kent Watsen
> Cc: Netconf (E-mail)
> Subject: Re: architecture and security
> 
> Kent Watsen wrote:
>> NSM also supports notifications thru its northbound interface.  The
> way
>> that we address access control is by authorizing the subscription
>> request.  This approach has proven ideal for us as it:
>>
>>   1. limits the system to only having to test client-initiated
> requests
>>   2. enables the system to add "implicit-filters" to the requests
>>   3. eliminates the system from having to apply filters to the
> responses
>> To understand the desire for implicit filters, please consider that
> the
>> system may implement granular access-controls such that an
> authenticated
>> user may only have access to a subset of a data repository.  For
>> instance, the user may only have access to a particular virtual system
>> (i.e. virtual router); from the user's perspective, the subscription
>> might be to "all events" but, upon receiving the request, the system's
>> access-control module might add an implicit-filter so that the request
>> then reads "all events where event->vsys == user->vsys" - after having
>> modified the incoming request, the access-control module can than pass
>> the request down into the system, which can remain unaware of
>> access-control issues...
> 
> I need to understand this architecture better.
> The WG agreed that a user-based access control model
> needs to be supported, but we never specified the details.
> 
> 
> So "user A" connects to your NB NSM API to receive notifications.
> 
> The NSM (as "user B") has a SB session to a netconf agent configured
> to send notifications.
> 
> Then "user C" connects to the netconf agent and causes a notification
> to be generated.
> 
> Let's use the (unexplained) example in sec. 5.1 of the draft.
> 
> The agent knows that user C has access to this <config> data.
> How does the agent know that the information in the <data> element,
> such as the operation performed, the interface name, or the mtu,
> can be viewed by user B?  How does the your NSM make sure that
> user A has proper access to this data?
> 
> I think the netconf standard architecture needs to account
> for the user C -> B scenario, but avoid proxy in the model
> at all costs (i.e., leave C -> B -> A out of the model).
> I think the access control granularity needs to be per-object
> at least, and per-instance in some use cases.
> 
> 
> 
>>
>> Kent
>>
> 
> Andy
> 
> 
>>
>>
>>
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
> On
>> Behalf Of Andy Bierman
>> Sent: Thursday, April 06, 2006 8:21 AM
>> To: Netconf (E-mail)
>> Subject: architecture and security
>>
>> Hi,
>>
>> I think the architecture for netconf notifications needs more
> attention.
>> The current draft tries to fit notifications into the existing model
>> for remote procedure calls.  The <rpc-one-way> is supposedly just
>> like a regular <rpc>, except it goes from the agent to the manager,
>> and there is no return value.  Also, the WG decided (based on
>> Junoscript experience) that returning <ok> was better than
>> no return value -- we explicitly don't want a 1-way-rpc --
>> in either direction.
>>
>>
>> There are 2 major problems with this architecture:
>>
>> 1) Headers are different becase the messages are different;
>>    Notifications have different general characteristics
>>    than RPC requests, so the headers will be different
>>    (e.g., no timestamp in an RPC request like a notification)
>>
>> 2) Access control is backwards;
>>    It doesn't make sense to apply access control to the '1 way RPC'
>>    in the same sense as a regular RPC.  It is the manager who is
>>    supposed to have access granted to view specific agent data -- not
>>    the agent that is supposed to have access granted to
>>    send the manager specific agent data.
>>
>>
>> Even though the term <rpc-one-way> is being removed, and the
>> message will be called <notification> instead (as it is on
>> page 17), we still need a secure architecture which scales well,
>> and will support a user-based access control model.
>> We need to think of how notifications fit into the base
>> netconf protocol, as well as existing security and NM protocols.
>> Operational issues and common use cases (e.g., building power-cycle)
>> need to be addressed.
>>
>> Once the requirements and architecture are understood,
>> we will be able to simplify and focus the API.  It isn't
>> acceptable to come to the conclusion that a feature is
>> a 95% lose-lose scenario, but we should do it anyway.
>>
>>
>> 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/>
> 
> 


--
to 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 Apr 06 18:40:44 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FRd9g-0002KM-Uq
	for netconf-archive@lists.ietf.org; Thu, 06 Apr 2006 18:40:44 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FRd9f-0001kv-JP
	for netconf-archive@lists.ietf.org; Thu, 06 Apr 2006 18:40:44 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FRd5o-0003Q5-8S
	for netconf-data@psg.com; Thu, 06 Apr 2006 22:36: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.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FRd5n-0003Pp-Hj
	for netconf@ops.ietf.org; Thu, 06 Apr 2006 22:36:43 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k36MagHx030615
	for <netconf@ops.ietf.org>; Thu, 6 Apr 2006 18:36:42 -0400
Received: (qmail 9121 invoked by uid 78); 6 Apr 2006 22:36:42 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.113 with SMTP; 6 Apr 2006 22:36:42 -0000
Message-ID: <443597F4.5090002@andybierman.com>
Date: Thu, 06 Apr 2006 15:36:36 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: example notification seems redundant
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: 7655788c23eb79e336f5f8ba8bce7906

Hi,

The examples in the notification draft aren't
very clear.  It seems like they must be intended
for a session other than the one that made the change,
because all of the info is redundant -- it would be implied
by an <ok>in the rpc-reply, or explicitly identified in the
<rpc-error> elements returned in the rpc-reply.

So why would config changes (ok or error) need to come right
back on the same session, duplicated in the form of a notification?

Wouldn't side effects (e.g., notification that says BGP4 started)
normally be monitored anyway by some notification receiver app?


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 Apr 06 23:51:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FRi0m-0004O3-Dp
	for netconf-archive@lists.ietf.org; Thu, 06 Apr 2006 23:51:52 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FRi0k-0002mh-4K
	for netconf-archive@lists.ietf.org; Thu, 06 Apr 2006 23:51:52 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FRhuZ-000NB6-8x
	for netconf-data@psg.com; Fri, 07 Apr 2006 03:45: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 autolearn=ham 
	version=3.1.1
Received: from [207.17.137.119] (helo=borg.juniper.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <kwatsen@juniper.net>)
	id 1FRhuY-000NAu-J0
	for netconf@ops.ietf.org; Fri, 07 Apr 2006 03:45:26 +0000
Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25])
  by borg.juniper.net with ESMTP; 06 Apr 2006 20:45:26 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.04,94,1144047600"; 
   d="scan'208"; a="541559740:sNHT23203888"
Received: from antitop.jnpr.net ([172.24.15.27]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 6 Apr 2006 20:45:25 -0700
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: architecture and security
Date: Thu, 6 Apr 2006 20:45:24 -0700
Message-ID: <B8C821F9E0675D44BFA994C28C0120E5E25089@antitop.jnpr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: architecture and security
Thread-Index: AcZZx90sL/mwYPn2Qcy3IOVJ1/dBQwAKB7Gg
From: "Kent Watsen" <kwatsen@juniper.net>
To: "Andy Bierman" <ietf@andybierman.com>
Cc: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 07 Apr 2006 03:45:25.0512 (UTC) FILETIME=[B4669880:01C659F5]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d


Andy wrote:
> So the agent has to check the filters to see if they can ever
> match a data model that the subscriber is not allowed to see,
> and reject the subscription request with an access-denied error.
>
> Or does the agent silently omit notifications which don't resolve
> to access-granted for that receiver?

Actually, both statements are true:=20

1. When the subscription-request comes in, the system must authenticate
that the request only subscribes to events the client is authorized to
receive

2. However, when each notification is generated by the system, the
system only forwards it to the client if it already has a subscription
in place for that kind of event

In case you think that I'm contradicting my earlier statement
"eliminates the system from having to apply filters to the responses",
what I meant to say is that it eliminates *access control* from having
to apply filters to the responses.  This is true since any notification
matching the subscription request, which was authorized, is also
implicitly authorized to be sent to the client


Kent


--
Kent Watsen
NSM Architect
Juniper Networks

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



From owner-netconf@ops.ietf.org Fri Apr 07 03:35:48 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FRlVT-0008H6-Qg
	for netconf-archive@lists.ietf.org; Fri, 07 Apr 2006 03:35:47 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FRlJo-0001Ie-Ot
	for netconf-archive@lists.ietf.org; Fri, 07 Apr 2006 03:23:46 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FRlDp-0009SO-Ab
	for netconf-data@psg.com; Fri, 07 Apr 2006 07:17:33 +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 1FRlDn-0009S9-UY
	for netconf@ops.ietf.org; Fri, 07 Apr 2006 07:17:32 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k377HUkQ017663
	for <netconf@ops.ietf.org>; Fri, 7 Apr 2006 03:17:30 -0400
Received: (qmail 27105 invoked by uid 78); 7 Apr 2006 07:17:30 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.116 with SMTP; 7 Apr 2006 07:17:30 -0000
Message-ID: <44361204.7080206@andybierman.com>
Date: Fri, 07 Apr 2006 00:17:24 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Kent Watsen <kwatsen@juniper.net>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: architecture and security
References: <B8C821F9E0675D44BFA994C28C0120E5E25089@antitop.jnpr.net>
In-Reply-To: <B8C821F9E0675D44BFA994C28C0120E5E25089@antitop.jnpr.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: e8a67952aa972b528dd04570d58ad8fe

Kent Watsen wrote:
> Andy wrote:
>> So the agent has to check the filters to see if they can ever
>> match a data model that the subscriber is not allowed to see,
>> and reject the subscription request with an access-denied error.
>>
>> Or does the agent silently omit notifications which don't resolve
>> to access-granted for that receiver?
> 
> Actually, both statements are true: 
> 
> 1. When the subscription-request comes in, the system must authenticate
> that the request only subscribes to events the client is authorized to
> receive
> 
> 2. However, when each notification is generated by the system, the
> system only forwards it to the client if it already has a subscription
> in place for that kind of event
> 
> In case you think that I'm contradicting my earlier statement
> "eliminates the system from having to apply filters to the responses",
> what I meant to say is that it eliminates *access control* from having
> to apply filters to the responses.  This is true since any notification
> matching the subscription request, which was authorized, is also
> implicitly authorized to be sent to the client


I don't think it is so simple.
Not all data on the agent is static.
There could be data that is not instantiated at
the time of the subscription request that the manager
is not allowed to see.  Therefore, the agent has to
check access control for each notification sent.

This assumes there is finer grained access control
than "all config events" or "all faults".  That would
not really be good enough to protect sensitive data.

> 
> 
> Kent

Andy

> 
> 
> --
> Kent Watsen
> NSM Architect
> Juniper Networks
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <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 Apr 07 08:00:25 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FRpdZ-0006c3-77
	for netconf-archive@lists.ietf.org; Fri, 07 Apr 2006 08:00:25 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FRpdX-0001aL-TV
	for netconf-archive@lists.ietf.org; Fri, 07 Apr 2006 08:00:25 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FRpXX-0002Al-Hw
	for netconf-data@psg.com; Fri, 07 Apr 2006 11:54: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 [47.140.192.56] (helo=zrtps0kp.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FRpXW-0002AX-E5
	for netconf@ops.ietf.org; Fri, 07 Apr 2006 11:54:10 +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 k37Bs6e27559
	for <netconf@ops.ietf.org>; Fri, 7 Apr 2006 07:54:06 -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: example notification seems redundant
Date: Fri, 7 Apr 2006 07:54:03 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407C73CB8@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: example notification seems redundant
Thread-Index: AcZZyz/9l6KbeDiLQB23Ip8BJI6ZpgAbSFtw
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: 4d87d2aa806f79fed918a62e834505ca




<Andy>

The examples in the notification draft aren't
very clear.  It seems like they must be intended
for a session other than the one that made the change,
because all of the info is redundant -- it would be implied
by an <ok>in the rpc-reply, or explicitly identified in the <rpc-error>
elements returned in the rpc-reply.

So why would config changes (ok or error) need to come right back on the
same session, duplicated in the form of a notification?

Wouldn't side effects (e.g., notification that says BGP4 started)
normally be monitored anyway by some notification receiver app?
<Andy>

I can interpret your question in two ways. Here is each of them

1. What redundant information? On a successful subscription, the request
returns the subscription ID, which is how you learn what it is. That
isn't redundant.

For the notifications themselves, they contain the subscription id, both
because you can have multiple subscriptions on a single connection and
because it is a nice indication that you are still receiving information
on the same subscription.

The only possible piece of redundant information, as Simon pointed out
in our offline meeting in Dallas is the messageId in the wrapper around
the notification.

2. There is no assumption that configuration changes will always be
applied on the same connection. Their are advantages to allowing a
mixing of notifications and certain commands (replay, modifying
subscriptions, reviewing information around notifications) and some
resource conscious deployments may choose to do everything on one
connection. Other deployments will break out some of the operations on
different connections. Plus, even if one did assume that everything was
done on a single connection, considering we are talking audit logs, you
would certainly want any configuration operations performed by people on
*different* connections to come through and not be just sent to the
possibly evil or incompetent person on the other connection.

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 Fri Apr 07 09:56:16 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FRrRg-0006en-Eo
	for netconf-archive@lists.ietf.org; Fri, 07 Apr 2006 09:56:16 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FRrRf-0005JN-1c
	for netconf-archive@lists.ietf.org; Fri, 07 Apr 2006 09:56:16 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FRrMT-000Bb8-PW
	for netconf-data@psg.com; Fri, 07 Apr 2006 13:50: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.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FRrMS-000Baj-Nl
	for netconf@ops.ietf.org; Fri, 07 Apr 2006 13:50:52 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k37DopkQ019416
	for <netconf@ops.ietf.org>; Fri, 7 Apr 2006 09:50:51 -0400
Received: (qmail 19488 invoked by uid 78); 7 Apr 2006 13:50:51 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.116 with SMTP; 7 Apr 2006 13:50:51 -0000
Message-ID: <44366E35.6050505@andybierman.com>
Date: Fri, 07 Apr 2006 06:50:45 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: example notification seems redundant
References: <713043CE8B8E1348AF3C546DBE02C1B407C73CB8@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B407C73CB8@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: 25620135586de10c627e3628c432b04a

Sharon Chisholm wrote:
> 
> 
> <Andy>
> 
> The examples in the notification draft aren't
> very clear.  It seems like they must be intended
> for a session other than the one that made the change,
> because all of the info is redundant -- it would be implied
> by an <ok>in the rpc-reply, or explicitly identified in the <rpc-error>
> elements returned in the rpc-reply.
> 
> So why would config changes (ok or error) need to come right back on the
> same session, duplicated in the form of a notification?
> 
> Wouldn't side effects (e.g., notification that says BGP4 started)
> normally be monitored anyway by some notification receiver app?
> <Andy>
> 
> I can interpret your question in two ways. Here is each of them
> 
> 1. What redundant information? On a successful subscription, the request
> returns the subscription ID, which is how you learn what it is. That
> isn't redundant.
> 
> For the notifications themselves, they contain the subscription id, both
> because you can have multiple subscriptions on a single connection and
> because it is a nice indication that you are still receiving information
> on the same subscription.
> 
> The only possible piece of redundant information, as Simon pointed out
> in our offline meeting in Dallas is the messageId in the wrapper around
> the notification.
> 
> 2. There is no assumption that configuration changes will always be
> applied on the same connection. Their are advantages to allowing a
> mixing of notifications and certain commands (replay, modifying
> subscriptions, reviewing information around notifications) and some
> resource conscious deployments may choose to do everything on one
> connection. Other deployments will break out some of the operations on
> different connections. Plus, even if one did assume that everything was
> done on a single connection, considering we are talking audit logs, you
> would certainly want any configuration operations performed by people on
> *different* connections to come through and not be just sent to the
> possibly evil or incompetent person on the other connection.
> 

Look at the <config> data in your example.
There is no explanation of what the notification
in sec 5.1 is supposed to be.  I assume it is a config-change.
Or a config-error.  My point is that for the manager that does
an <edit-config> which supposedly caused this notification,
there is no value in the notification at all.  All of the info
is contained in the <rpc-reply> already.

So the notion the receiving notifications on the same session
as operations will somehow makes the operations easier -- is wrong.
The only benefit is that it saves the memory overhead of 1 session,
in exchange for the complexity and lose-lose operational
characteristics of a shared session.

IMO, the examples in the draft are more suitable for traditional
notification generator applications.

> 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 Fri Apr 07 11:50:33 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FRtEH-0007TE-57
	for netconf-archive@lists.ietf.org; Fri, 07 Apr 2006 11:50:33 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FRtED-0000xk-Nq
	for netconf-archive@lists.ietf.org; Fri, 07 Apr 2006 11:50:33 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FRt9t-000L24-Az
	for netconf-data@psg.com; Fri, 07 Apr 2006 15:46: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,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 1FRt9q-000L1T-Ex
	for netconf@ops.ietf.org; Fri, 07 Apr 2006 15:45:58 +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 k37Fjtn14600
	for <netconf@ops.ietf.org>; Fri, 7 Apr 2006 11:45:55 -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: example notification seems redundant
Date: Fri, 7 Apr 2006 11:45:50 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407C7422F@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: example notification seems redundant
Thread-Index: AcZaSl5A8TJ8cZNMQkaAm7QxteMtWAADz8CA
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: 9a2be21919e71dc6faef12b370c4ecf5

hi

There are really then three different use cases at work here

1) I am the originator of the request and I would like some concise
indication that things worked out OK in the end for some reason or other

2) I am creating an audit log and need to know exactly what was done and
by whom and how

3) I am a user of the configuration information and need to know what
information has been changed. This covers the cases of configuration
mirroring, configuration applications and people just interested in the
device inventory for whatever reason.=20

The example content in the appendixes cover the second and the third
cases. I believe the message content is different for the three use
cases.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]=20
Sent: Friday, April 07, 2006 9:51 AM
To: Chisholm, Sharon [CAR:ZZ00:EXCH]
Cc: Netconf (E-mail)
Subject: Re: example notification seems redundant


Sharon Chisholm wrote:
>=20
>=20
> <Andy>
>=20
> The examples in the notification draft aren't
> very clear.  It seems like they must be intended
> for a session other than the one that made the change, because all of=20
> the info is redundant -- it would be implied by an <ok>in the=20
> rpc-reply, or explicitly identified in the <rpc-error> elements=20
> returned in the rpc-reply.
>=20
> So why would config changes (ok or error) need to come right back on=20
> the same session, duplicated in the form of a notification?
>=20
> Wouldn't side effects (e.g., notification that says BGP4 started)=20
> normally be monitored anyway by some notification receiver app? <Andy>
>=20
> I can interpret your question in two ways. Here is each of them
>=20
> 1. What redundant information? On a successful subscription, the=20
> request returns the subscription ID, which is how you learn what it=20
> is. That isn't redundant.
>=20
> For the notifications themselves, they contain the subscription id,=20
> both because you can have multiple subscriptions on a single=20
> connection and because it is a nice indication that you are still=20
> receiving information on the same subscription.
>=20
> The only possible piece of redundant information, as Simon pointed out

> in our offline meeting in Dallas is the messageId in the wrapper=20
> around the notification.
>=20
> 2. There is no assumption that configuration changes will always be=20
> applied on the same connection. Their are advantages to allowing a=20
> mixing of notifications and certain commands (replay, modifying=20
> subscriptions, reviewing information around notifications) and some=20
> resource conscious deployments may choose to do everything on one=20
> connection. Other deployments will break out some of the operations on

> different connections. Plus, even if one did assume that everything=20
> was done on a single connection, considering we are talking audit=20
> logs, you would certainly want any configuration operations performed=20
> by people on
> *different* connections to come through and not be just sent to the
> possibly evil or incompetent person on the other connection.
>=20

Look at the <config> data in your example.
There is no explanation of what the notification
in sec 5.1 is supposed to be.  I assume it is a config-change. Or a
config-error.  My point is that for the manager that does an
<edit-config> which supposedly caused this notification, there is no
value in the notification at all.  All of the info is contained in the
<rpc-reply> already.

So the notion the receiving notifications on the same session as
operations will somehow makes the operations easier -- is wrong. The
only benefit is that it saves the memory overhead of 1 session, in
exchange for the complexity and lose-lose operational characteristics of
a shared session.

IMO, the examples in the draft are more suitable for traditional
notification generator applications.

> 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 Fri Apr 07 13:15:47 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FRuYl-0008TP-2I
	for netconf-archive@lists.ietf.org; Fri, 07 Apr 2006 13:15:47 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FRuYj-0004pD-Oa
	for netconf-archive@lists.ietf.org; Fri, 07 Apr 2006 13:15:47 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FRuT4-0002X2-Pq
	for netconf-data@psg.com; Fri, 07 Apr 2006 17:09: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.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 1FRuT3-0002Wp-Og
	for netconf@ops.ietf.org; Fri, 07 Apr 2006 17:09:53 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k37H9qHx029758
	for <netconf@ops.ietf.org>; Fri, 7 Apr 2006 13:09:52 -0400
Received: (qmail 17919 invoked by uid 78); 7 Apr 2006 17:09:52 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.113 with SMTP; 7 Apr 2006 17:09:52 -0000
Message-ID: <44369CDA.2070308@andybierman.com>
Date: Fri, 07 Apr 2006 10:09:46 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: example notification seems redundant
References: <713043CE8B8E1348AF3C546DBE02C1B407C7422F@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B407C7422F@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: 02ec665d00de228c50c93ed6b5e4fc1a

Sharon Chisholm wrote:
> hi
> 
> There are really then three different use cases at work here
> 
> 1) I am the originator of the request and I would like some concise
> indication that things worked out OK in the end for some reason or other
> 

We have <rpc-reply> for this already.

> 2) I am creating an audit log and need to know exactly what was done and
> by whom and how

This is a use case for a traditional dedicated notification
generator -> receiver application.

> 
> 3) I am a user of the configuration information and need to know what
> information has been changed. This covers the cases of configuration
> mirroring, configuration applications and people just interested in the
> device inventory for whatever reason. 

There are several ways to do this already, such as
retrieving the configuration before the change and
again after the configuration.  The application
making the changes should also know, otherwise
it might carelessly clobber existing config data.

However, this still seems like a use case for the
traditional centralized notification service, not a
per-session model.

I am in favor of a netconf capability for notifications,
which means delivery of content-independent notifications
on a session (mandatory: dedicated; optional: mixed).

The syslog WG is going to have to be responsible for
standardizing syslog content, not the netconf WG.
Beyond a standard content type wrapper for <syslog-text>, and
maybe <syslog-xml>, I don't believe the netconf WG
is the right place to work on syslog.


> 
> The example content in the appendixes cover the second and the third
> cases. I believe the message content is different for the three use
> cases.

What page #s?

> 
> 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 Fri Apr 07 13:45:47 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FRv0z-0000pD-Hh
	for netconf-archive@lists.ietf.org; Fri, 07 Apr 2006 13:44:57 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FRunL-0005NX-EG
	for netconf-archive@lists.ietf.org; Fri, 07 Apr 2006 13:30:52 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FRuj3-0003ui-0O
	for netconf-data@psg.com; Fri, 07 Apr 2006 17:26: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 [47.129.242.56] (helo=zcars04e.nortel.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <schishol@nortel.com>)
	id 1FRuiz-0003uS-O2
	for netconf@ops.ietf.org; Fri, 07 Apr 2006 17:26:22 +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 k37HLiV24886
	for <netconf@ops.ietf.org>; Fri, 7 Apr 2006 13:21: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: example notification seems redundant
Date: Fri, 7 Apr 2006 13:26:15 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407CDE3C5@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: example notification seems redundant
Thread-Index: AcZaZhqvjF4WHRW7Qfyr+ds8i7by4QAAUSJQ
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: c3a18ef96977fc9bcc21a621cbf1174b

hi

Your the one who brought up the content discussion :-) As previously
indicated, there are significant benefits to being able to send
notifications with Netconf content. In addition, there are some gaps
between existing solutions and what is required. If you make too many
changes to existing solutions, they risk not interoperating with
deployed versions of itself. You risk ending up with the worst of both
worlds - a new protocol and one that still requires expensive mediation
to exchange information with Netconf-based ones.

The content discussion I was referring to is in Appendix B1, starting on
page 38.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]=20
Sent: Friday, April 07, 2006 1:10 PM
To: Chisholm, Sharon [CAR:ZZ00:EXCH]
Cc: Netconf (E-mail)
Subject: Re: example notification seems redundant


Sharon Chisholm wrote:
> hi
>=20
> There are really then three different use cases at work here
>=20
> 1) I am the originator of the request and I would like some concise=20
> indication that things worked out OK in the end for some reason or=20
> other
>=20

We have <rpc-reply> for this already.

> 2) I am creating an audit log and need to know exactly what was done=20
> and by whom and how

This is a use case for a traditional dedicated notification generator ->
receiver application.

>=20
> 3) I am a user of the configuration information and need to know what=20
> information has been changed. This covers the cases of configuration=20
> mirroring, configuration applications and people just interested in=20
> the device inventory for whatever reason.

There are several ways to do this already, such as
retrieving the configuration before the change and
again after the configuration.  The application
making the changes should also know, otherwise
it might carelessly clobber existing config data.

However, this still seems like a use case for the
traditional centralized notification service, not a
per-session model.

I am in favor of a netconf capability for notifications,
which means delivery of content-independent notifications
on a session (mandatory: dedicated; optional: mixed).

The syslog WG is going to have to be responsible for standardizing
syslog content, not the netconf WG. Beyond a standard content type
wrapper for <syslog-text>, and maybe <syslog-xml>, I don't believe the
netconf WG is the right place to work on syslog.


>=20
> The example content in the appendixes cover the second and the third=20
> cases. I believe the message content is different for the three use=20
> cases.

What page #s?

>=20
> 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 Fri Apr 07 14:27:36 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FRvgG-0004Zu-1X
	for netconf-archive@lists.ietf.org; Fri, 07 Apr 2006 14:27:36 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FRvgE-0000Nr-Il
	for netconf-archive@lists.ietf.org; Fri, 07 Apr 2006 14:27:36 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FRvbK-00080H-4O
	for netconf-data@psg.com; Fri, 07 Apr 2006 18:22: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.53] (helo=ns-omrbm3.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FRvbI-000804-Jc
	for netconf@ops.ietf.org; Fri, 07 Apr 2006 18:22:28 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k37IMQHx012282
	for <netconf@ops.ietf.org>; Fri, 7 Apr 2006 14:22:27 -0400
Received: (qmail 9247 invoked by uid 78); 7 Apr 2006 18:22:26 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.113 with SMTP; 7 Apr 2006 18:22:26 -0000
Message-ID: <4436ADDC.8080707@andybierman.com>
Date: Fri, 07 Apr 2006 11:22:20 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: example notification seems redundant
References: <713043CE8B8E1348AF3C546DBE02C1B407CDE3C5@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B407CDE3C5@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: 8f374d0786b25a451ef87d82c076f593

Sharon Chisholm wrote:
> hi
> 
> Your the one who brought up the content discussion :-) As previously
> indicated, there are significant benefits to being able to send
> notifications with Netconf content. In addition, there are some gaps
> between existing solutions and what is required. If you make too many
> changes to existing solutions, they risk not interoperating with
> deployed versions of itself. You risk ending up with the worst of both
> worlds - a new protocol and one that still requires expensive mediation
> to exchange information with Netconf-based ones.
> 
> The content discussion I was referring to is in Appendix B1, starting on
> page 38.

I am only concerned with content as part of understanding
the access control model that is needed to limit
access to particular content.

I don't think the non-normative appendices are going to
stay in this document.  The WG is going to agree on
specific notification content (if any) and it will
be normative text.  Anything else will be removed from
the document.

XML already provides a way for us to implement a
content-independent protocol.  Just like for the
<config> element in RPC operations, a namespace is
used to link the content to a schema.

So our document does not even need to define content types.
Event classes can just be strings in the protocol.

Let's say one wanted to use RFC 3195 COOKED mode syslog
(even though it uses attributes instead of elements).
Here how the example from page 24 might look in netconf:


<notification xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <type>syslog</type>
   <sequence>1034</sequence>
   <timestamp>2006-05-07T11:30:00.000-08:00</timestamp>
   <data>
     <entry xmlns="http://iana.org/beep/SYSLOG/COOKED"
        facility="24" severity="5"
        timestamp="Oct 27 13:24:12"
        deviceFQDN="screen.lowry.records.example.com"
        deviceIP="10.0.0.47"
        pathID="173" tag="dvd"/>
     </entry>
   </data>
</notification>


So standard data models for notification content can continue
in parallel with standard data models for configuration,
after the protocol extension is done.  It's just a different
content layer namespace in the protocol.


> 
> Sharon

Andy


> 
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com] 
> Sent: Friday, April 07, 2006 1:10 PM
> To: Chisholm, Sharon [CAR:ZZ00:EXCH]
> Cc: Netconf (E-mail)
> Subject: Re: example notification seems redundant
> 
> 
> Sharon Chisholm wrote:
>> hi
>>
>> There are really then three different use cases at work here
>>
>> 1) I am the originator of the request and I would like some concise 
>> indication that things worked out OK in the end for some reason or 
>> other
>>
> 
> We have <rpc-reply> for this already.
> 
>> 2) I am creating an audit log and need to know exactly what was done 
>> and by whom and how
> 
> This is a use case for a traditional dedicated notification generator ->
> receiver application.
> 
>> 3) I am a user of the configuration information and need to know what 
>> information has been changed. This covers the cases of configuration 
>> mirroring, configuration applications and people just interested in 
>> the device inventory for whatever reason.
> 
> There are several ways to do this already, such as
> retrieving the configuration before the change and
> again after the configuration.  The application
> making the changes should also know, otherwise
> it might carelessly clobber existing config data.
> 
> However, this still seems like a use case for the
> traditional centralized notification service, not a
> per-session model.
> 
> I am in favor of a netconf capability for notifications,
> which means delivery of content-independent notifications
> on a session (mandatory: dedicated; optional: mixed).
> 
> The syslog WG is going to have to be responsible for standardizing
> syslog content, not the netconf WG. Beyond a standard content type
> wrapper for <syslog-text>, and maybe <syslog-xml>, I don't believe the
> netconf WG is the right place to work on syslog.
> 
> 
>> The example content in the appendixes cover the second and the third 
>> cases. I believe the message content is different for the three use 
>> cases.
> 
> What page #s?
> 
>> 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 Fri Apr 07 15:09:07 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FRwKR-0007N2-4w
	for netconf-archive@lists.ietf.org; Fri, 07 Apr 2006 15:09:07 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FRwKP-0002FW-OG
	for netconf-archive@lists.ietf.org; Fri, 07 Apr 2006 15:09:07 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FRwHG-000BSX-4A
	for netconf-data@psg.com; Fri, 07 Apr 2006 19:05: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.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 1FRwHF-000BSJ-1s
	for netconf@ops.ietf.org; Fri, 07 Apr 2006 19:05:49 +0000
Received: from localhost (c213-100-166-180.swipnet.se [213.100.166.180])
	(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.tail-f.com (Postfix) with ESMTP id EFBAA59;
	Fri,  7 Apr 2006 21:05:47 +0200 (CEST)
Date: Fri, 07 Apr 2006 21:05:38 +0200 (CEST)
Message-Id: <20060407.210538.100368859.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: netconf@ops.ietf.org
Subject: Re: architecture and security
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <443531F3.7000903@andybierman.com>
References: <443531F3.7000903@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: 7d33c50f3756db14428398e2bdedd581

Andy Bierman <ietf@andybierman.com> wrote:
> 2) Access control is backwards;
>    It doesn't make sense to apply access control to the '1 way RPC'
>    in the same sense as a regular RPC.  It is the manager who is
>    supposed to have access granted to view specific agent data -- not
>    the agent that is supposed to have access granted to
>    send the manager specific agent data.

Could you elaborate on what the problem is?  Is this different/more
problematic than the SNMP VACM model?  I.e. can't you use a "notify"
view, and apply it to each notification generated by the agent?  Also,
I think the filter-based approach that Kent described can be seen as
one way to implement this model (if I understand him correctly).


/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 Apr 07 15:20:31 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FRwVT-0005tU-0M
	for netconf-archive@lists.ietf.org; Fri, 07 Apr 2006 15:20:31 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FRwVR-0002og-Mz
	for netconf-archive@lists.ietf.org; Fri, 07 Apr 2006 15:20:30 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FRwRg-000CK3-BL
	for netconf-data@psg.com; Fri, 07 Apr 2006 19:16: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.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 1FRwRf-000CJq-G8
	for netconf@ops.ietf.org; Fri, 07 Apr 2006 19:16:35 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k37JGYkQ012873
	for <netconf@ops.ietf.org>; Fri, 7 Apr 2006 15:16:34 -0400
Received: (qmail 7744 invoked by uid 78); 7 Apr 2006 19:16:34 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.116 with SMTP; 7 Apr 2006 19:16:34 -0000
Message-ID: <4436BA8C.5020708@andybierman.com>
Date: Fri, 07 Apr 2006 12:16:28 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC: netconf@ops.ietf.org
Subject: Re: architecture and security
References: <443531F3.7000903@andybierman.com> <20060407.210538.100368859.mbj@tail-f.com>
In-Reply-To: <20060407.210538.100368859.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: e1e48a527f609d1be2bc8d8a70eb76cb

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>> 2) Access control is backwards;
>>    It doesn't make sense to apply access control to the '1 way RPC'
>>    in the same sense as a regular RPC.  It is the manager who is
>>    supposed to have access granted to view specific agent data -- not
>>    the agent that is supposed to have access granted to
>>    send the manager specific agent data.
> 
> Could you elaborate on what the problem is?  Is this different/more
> problematic than the SNMP VACM model?  I.e. can't you use a "notify"
> view, and apply it to each notification generated by the agent?  Also,
> I think the filter-based approach that Kent described can be seen as
> one way to implement this model (if I understand him correctly).

Yes.
But my point is that the backwards 1-way RPC also reverses
the access control (incorrectly).

IMO, for the subscribe type of API, a profile name is
specified which points to all the parameters, such as
the access-control view to use.

The agent uses that access control profile when generating
each notification, to check it against the contained content.
If the user is allowed to see all the data, the notification is
sent, otherwise it is simply not sent to that user (i.e., on that
session).

> 
> 
> /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 Mon Apr 10 10:38:02 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FSxWk-00066I-JE
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 10:38:02 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FSxWk-00043I-9k
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 10:38:02 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FSxO1-000CJM-5v
	for netconf-data@psg.com; Mon, 10 Apr 2006 14:29: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.50] (helo=omr1.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FSxO0-000CJA-1f
	for netconf@ops.ietf.org; Mon, 10 Apr 2006 14:29:00 +0000
Received: from mail.networksolutionsemail.com (omr1.mgt.bos.netsol.com [10.49.2.111] (may be forged))
	by omr1.networksolutionsemail.com (8.12.10/8.12.10) with SMTP id k3AESwZj011763
	for <netconf@ops.ietf.org>; Mon, 10 Apr 2006 10:28:58 -0400
Received: (qmail 10064 invoked by uid 78); 10 Apr 2006 14:28:58 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.111 with SMTP; 10 Apr 2006 14:28:58 -0000
Message-ID: <443A6C1E.6080203@andybierman.com>
Date: Mon, 10 Apr 2006 07:30:54 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: design: special RPC vs. data 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f

Hi,

I think the WG should understand and write down the
architecture for netconf wrt/ its use within a
network management system (not just netconf, not just 1 device).
That is not our charter at this time, so we don't
have to write an entire document, but we do have to consider
the overall architecture in the notification work.

For starters, we already have a 'traditional' model
where a manager manipulates configuration databases
on the agent, using standard RPC methods like edit-config.

Although specialized RPC methods like create-subscription
are always possible in netconf, they are not always the
best design choice.  We don't seem to have any criteria
for deciding whether to use custom RPC methods or a data model
manipulated with the standard RPC methods.

The current draft has custom RPC methods, plus a mandatory
read-only data model for use with the standard method <get>.
I don't understand this architecture.  If the manager is
sending session-specific parameters (and that's why a
custom RPC is appropriate), then why do we need a global
data model for others to read back the settings
in use for all the various sessions?   If these are
not session-specific parameters, then why not use the
traditional read-create data model + standard methods approach?


Andy


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



From owner-netconf@ops.ietf.org Mon Apr 10 14:09:36 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FT0pU-0007jT-TE
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 14:09:36 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FT0pU-0004Y9-J9
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 14:09:36 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FT0lN-000Pvh-Cs
	for netconf-data@psg.com; Mon, 10 Apr 2006 18:05: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.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1
Received: from [207.69.195.65] (helo=pop-scotia.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <randy_presuhn@mindspring.com>)
	id 1FT0lL-000PvT-PL
	for netconf@ops.ietf.org; Mon, 10 Apr 2006 18:05:20 +0000
Received: from h-68-166-189-141.snvacaid.dynamic.covad.net ([68.166.189.141] helo=oemcomputer)
	by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1FT0lK-0004Iz-00
	for netconf@ops.ietf.org; Mon, 10 Apr 2006 14:05:19 -0400
Message-ID: <008b01c65cc9$ceeda320$6401a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
References: <B8C821F9E0675D44BFA994C28C0120E5E25089@antitop.jnpr.net>
Subject: Re: architecture and security
Date: Mon, 10 Apr 2006 11:08:44 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb

Hi -

> From: "Kent Watsen" <kwatsen@juniper.net>
> To: "Andy Bierman" <ietf@andybierman.com>
> Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
> Sent: Thursday, April 06, 2006 8:45 PM
> Subject: RE: architecture and security
...
> 1. When the subscription-request comes in, the system must authenticate
> that the request only subscribes to events the client is authorized to
> receive
>
> 2. However, when each notification is generated by the system, the
> system only forwards it to the client if it already has a subscription
> in place for that kind of event
>
> In case you think that I'm contradicting my earlier statement
> "eliminates the system from having to apply filters to the responses",
> what I meant to say is that it eliminates *access control* from having
> to apply filters to the responses.  This is true since any notification
> matching the subscription request, which was authorized, is also
> implicitly authorized to be sent to the client
...

It sounds like these access control policies are only in terms
of the event type, and not in terms of the specific resources
being managed.  In other words, if Customer A should only
be able to access interface (a) configuration data,
and Customer B should only be able to access interface (b),
and the same event type is defined for both interfaces,
we'd have a problem.

Or is this simply one of those things netconf won't support?

Randy


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



From owner-netconf@ops.ietf.org Mon Apr 10 15:04:48 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FT1gu-0006e3-UF
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 15:04:48 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FT1gt-0006vC-LL
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 15:04:48 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FT1cb-0003fj-OR
	for netconf-data@psg.com; Mon, 10 Apr 2006 19: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.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1
Received: from [207.69.195.64] (helo=pop-knobcone.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <randy_presuhn@mindspring.com>)
	id 1FT1cZ-0003fK-FR
	for netconf@ops.ietf.org; Mon, 10 Apr 2006 19:00:21 +0000
Received: from h-68-166-189-141.snvacaid.dynamic.covad.net ([68.166.189.141] helo=oemcomputer)
	by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1FT1cY-0005fO-00
	for netconf@ops.ietf.org; Mon, 10 Apr 2006 15:00:18 -0400
Message-ID: <000801c65cd1$83f48c00$6401a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
References: <Pine.LNX.4.10.10604101126230.13053-100000@shell4.bayarea.net>
Subject: Re: architecture and security
Date: Mon, 10 Apr 2006 12:03:54 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007

Hi -
 
> From: "David T. Perkins" <dperkins@dsperkins.com>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
> Sent: Monday, April 10, 2006 11:34 AM
> Subject: Re: architecture and security
... 
> Given the desire "to make part of management information
> such as that for a single interface available to users
> of that part and not to other users", SNMPv3 attempts
> to do this via setting up VACM authorization rules.
> The result is an inconsistent set of management info.
...

How so?

Randy


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



From owner-netconf@ops.ietf.org Mon Apr 10 15:23:39 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FT1z9-00064V-CU
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 15:23:39 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FT1z9-0007w6-3B
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 15:23:39 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FT1vL-00051x-4c
	for netconf-data@psg.com; Mon, 10 Apr 2006 19:19: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.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 1FT1vK-00051k-0N
	for netconf@ops.ietf.org; Mon, 10 Apr 2006 19:19:42 +0000
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k3AJJdkK022586;
	Mon, 10 Apr 2006 12:19:40 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k3AJJbfg022571;
	Mon, 10 Apr 2006 12:19:37 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Mon, 10 Apr 2006 12:19:37 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Randy Presuhn <randy_presuhn@mindspring.com>
cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: architecture and security
In-Reply-To: <000801c65cd1$83f48c00$6401a8c0@oemcomputer>
Message-ID: <Pine.LNX.4.10.10604101214000.13053-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: a7d6aff76b15f3f56fcb94490e1052e4

HI,

Consider ifNumber. If a device has, say, 4 interfaces,
but only a single one allows access to management info,
then it appears that the management info is incorrect,
since ifNumber will be 4 but only one interface is
in the table.
If you go through all MIB modules and try to set up
VACM so that a limited set of info is available, then
you will most likely end up with a set of management
info that is accessible that appears is coming
from a broken SNMP agent. 

You have to go through each on a case by case bases.

On Mon, 10 Apr 2006, Randy Presuhn wrote:
> Hi -
>  
> > From: "David T. Perkins" <dperkins@dsperkins.com>
> > To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> > Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
> > Sent: Monday, April 10, 2006 11:34 AM
> > Subject: Re: architecture and security
> ... 
> > Given the desire "to make part of management information
> > such as that for a single interface available to users
> > of that part and not to other users", SNMPv3 attempts
> > to do this via setting up VACM authorization rules.
> > The result is an inconsistent set of management info.
> ...
> 
> How so?
> 
> Randy
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 Mon Apr 10 15:57:57 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FT2WL-00060d-Nt
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 15:57:57 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FT2WK-0001IJ-4m
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 15:57:57 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FT2RL-00074D-ON
	for netconf-data@psg.com; Mon, 10 Apr 2006 19:52: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.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 1FT2RI-00073w-Ln
	for netconf@ops.ietf.org; Mon, 10 Apr 2006 19:52:45 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id DDC3155D8C;
	Mon, 10 Apr 2006 21:52:43 +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 09811-08; Mon, 10 Apr 2006 21:52:42 +0200 (CEST)
Received: from boskop.local (unknown [10.222.1.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id E3F0355C63;
	Mon, 10 Apr 2006 21:52:41 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id 9835D6A22D4; Mon, 10 Apr 2006 21:52:39 +0200 (CEST)
Date: Mon, 10 Apr 2006 21:52:39 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Randy Presuhn <randy_presuhn@mindspring.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: architecture and security
Message-ID: <20060410195239.GA4952@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Randy Presuhn <randy_presuhn@mindspring.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
References: <Pine.LNX.4.10.10604101126230.13053-100000@shell4.bayarea.net> <000801c65cd1$83f48c00$6401a8c0@oemcomputer>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000801c65cd1$83f48c00$6401a8c0@oemcomputer>
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 Mon, Apr 10, 2006 at 12:03:54PM -0700, Randy Presuhn wrote:

> > Given the desire "to make part of management information
> > such as that for a single interface available to users
> > of that part and not to other users", SNMPv3 attempts
> > to do this via setting up VACM authorization rules.
> > The result is an inconsistent set of management info.
> ...
> 
> How so?

I tend to agree with Dave Perkins.

I have recently looked at a different problem, namely the
anonymization (or pseudonymization) of management traffic and
configurations and it is virtually impossible to get this right since
information leaks through very easily (just consider an IPv6 address
derived from an IEEE MAC address which is then used to derive an
SnmpEngineID - and now your task is to anonymize the MAC address).
While it might be possible to get things right for a given device with
enough man-power for standard read-only tables (and I very much doubt
that someone is willing spending this money for a single device while
the next device means you have to repeat major parts of the exercise
due to many private MIB objects), things melt down quite quickly once
you face tables where users can name entries or even put descriptions
or other opaque things into an agent. Operationally useful names
usually carry quite a bit of context (this is exactly why they are
useful to operators) and so it is very likely that information leaks
through these descriptions.

Talking about VACM: VACM fails by design when it comes to situations
where the item you want to base your access control decision is not in
the OID.  No, I am not asking for a VACM++ - this would only help in
theory and make things worse in practice.

I believe that in practice, we need the implementations to help us do
the right thing for a given set of well understood and defined
profiles. Dave's idea to provide views by means of virtualized devices
surely sounds interesting, although probably too far reaching for IETF
work.

/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 Mon Apr 10 16:05:37 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FT2dl-0007LV-Mn
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 16:05:37 -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 1FT1mH-0007K5-GH
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 15:10:21 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FT1Ir-0004yH-D4
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 14:39:59 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FT1Dt-0001rE-T5
	for netconf-data@psg.com; Mon, 10 Apr 2006 18:34: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 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 1FT1Dt-0001r2-48
	for netconf@ops.ietf.org; Mon, 10 Apr 2006 18:34:49 +0000
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k3AIYkoZ007464;
	Mon, 10 Apr 2006 11:34:46 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k3AIYjoP007458;
	Mon, 10 Apr 2006 11:34:46 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Mon, 10 Apr 2006 11:34:45 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Randy Presuhn <randy_presuhn@mindspring.com>
cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: architecture and security
In-Reply-To: <008b01c65cc9$ceeda320$6401a8c0@oemcomputer>
Message-ID: <Pine.LNX.4.10.10604101126230.13053-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: -2.6 (--)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88

HI,

This goes back to modeling vs authorization.

Given the desire "to make part of management information
such as that for a single interface available to users
of that part and not to other users", SNMPv3 attempts
to do this via setting up VACM authorization rules.
The result is an inconsistent set of management info.
Another approach is to create a virtual device
that appears as simple and implements only the
functions that a user is authorized to access
management info. And finally, the management info
can be collected from the device and made available
in another format (and data model).

I see the authorization approach as a temporary
quick fix that sort of works in limited cases.

Regards,
/david t. perkins

On Mon, 10 Apr 2006, Randy Presuhn wrote:

> Hi -
> 
> > From: "Kent Watsen" <kwatsen@juniper.net>
> > To: "Andy Bierman" <ietf@andybierman.com>
> > Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
> > Sent: Thursday, April 06, 2006 8:45 PM
> > Subject: RE: architecture and security
> ...
> > 1. When the subscription-request comes in, the system must authenticate
> > that the request only subscribes to events the client is authorized to
> > receive
> >
> > 2. However, when each notification is generated by the system, the
> > system only forwards it to the client if it already has a subscription
> > in place for that kind of event
> >
> > In case you think that I'm contradicting my earlier statement
> > "eliminates the system from having to apply filters to the responses",
> > what I meant to say is that it eliminates *access control* from having
> > to apply filters to the responses.  This is true since any notification
> > matching the subscription request, which was authorized, is also
> > implicitly authorized to be sent to the client
> ...
> 
> It sounds like these access control policies are only in terms
> of the event type, and not in terms of the specific resources
> being managed.  In other words, if Customer A should only
> be able to access interface (a) configuration data,
> and Customer B should only be able to access interface (b),
> and the same event type is defined for both interfaces,
> we'd have a problem.
> 
> Or is this simply one of those things netconf won't support?
> 
> Randy
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <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 Apr 10 16:32:28 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FT33k-0002Rd-Te
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 16:32:28 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FT33g-0003Fx-Iz
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 16:32:28 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FT2zr-0009GU-1J
	for netconf-data@psg.com; Mon, 10 Apr 2006 20:28: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.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1
Received: from [207.69.195.65] (helo=pop-scotia.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <randy_presuhn@mindspring.com>)
	id 1FT2zq-0009GH-E2
	for netconf@ops.ietf.org; Mon, 10 Apr 2006 20:28:26 +0000
Received: from h-68-166-189-141.snvacaid.dynamic.covad.net ([68.166.189.141] helo=oemcomputer)
	by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1FT2zp-0005IK-00
	for netconf@ops.ietf.org; Mon, 10 Apr 2006 16:28:25 -0400
Message-ID: <000d01c65cdd$d1d40a20$6401a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
References: <Pine.LNX.4.10.10604101214000.13053-100000@shell4.bayarea.net>
Subject: Re: architecture and security
Date: Mon, 10 Apr 2006 13:31:59 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1

Hi -

> From: "David T. Perkins" <dperkins@dsperkins.com>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
> Sent: Monday, April 10, 2006 12:19 PM
> Subject: Re: architecture and security
...
> Consider ifNumber. If a device has, say, 4 interfaces,
> but only a single one allows access to management info,
> then it appears that the management info is incorrect,
> since ifNumber will be 4 but only one interface is
> in the table.

No, it means only one interface could be accessed.
Since my ATM card allows me to access only three
accounts, would it be reasonable to conclude that my
bank only has three customer accounts?  Of course not.
We should not see inconsistancy where there are merely
unwarranted inferences.

> If you go through all MIB modules and try to set up
> VACM so that a limited set of info is available, then
> you will most likely end up with a set of management
> info that is accessible that appears is coming
> from a broken SNMP agent. 
...

More likely, an application that is making inferences that
are not justified.

Randy


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



From owner-netconf@ops.ietf.org Mon Apr 10 16:40:42 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FT3Bi-0007OJ-AK
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 16:40:42 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FT3Bg-0003eu-Vu
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 16:40:42 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FT37W-0009oJ-Ae
	for netconf-data@psg.com; Mon, 10 Apr 2006 20: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.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1
Received: from [207.69.195.65] (helo=pop-scotia.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <randy_presuhn@mindspring.com>)
	id 1FT37U-0009nq-0Z
	for netconf@ops.ietf.org; Mon, 10 Apr 2006 20:36:21 +0000
Received: from h-68-166-189-141.snvacaid.dynamic.covad.net ([68.166.189.141] helo=oemcomputer)
	by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1FT37T-0000cc-00
	for netconf@ops.ietf.org; Mon, 10 Apr 2006 16:36:19 -0400
Message-ID: <001601c65cde$ee05f220$6401a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
References: <Pine.LNX.4.10.10604101126230.13053-100000@shell4.bayarea.net> <000801c65cd1$83f48c00$6401a8c0@oemcomputer> <20060410195239.GA4952@boskop.local>
Subject: Re: architecture and security
Date: Mon, 10 Apr 2006 13:39:56 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081

Hi -

> From: "Juergen Schoenwaelder" <j.schoenwaelder@iu-bremen.de>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
> Sent: Monday, April 10, 2006 12:52 PM
> Subject: Re: architecture and security
... 
> I have recently looked at a different problem, namely the
> anonymization (or pseudonymization) of management traffic and
> configurations and it is virtually impossible to get this right since
> information leaks through very easily (just consider an IPv6 address
> derived from an IEEE MAC address which is then used to derive an
> SnmpEngineID - and now your task is to anonymize the MAC address).
> While it might be possible to get things right for a given device with
> enough man-power for standard read-only tables (and I very much doubt
> that someone is willing spending this money for a single device while
> the next device means you have to repeat major parts of the exercise
> due to many private MIB objects), things melt down quite quickly once
> you face tables where users can name entries or even put descriptions
> or other opaque things into an agent. Operationally useful names
> usually carry quite a bit of context (this is exactly why they are
> useful to operators) and so it is very likely that information leaks
> through these descriptions.

No disagreement on this point, but I think it is quite a different one from
the claim that VACM causes management information to become
inconsistent.

> Talking about VACM: VACM fails by design when it comes to situations
> where the item you want to base your access control decision is not in
> the OID.  No, I am not asking for a VACM++ - this would only help in
> theory and make things worse in practice.
...

Again, no disagreement.  I think the issue for netconf is just what is
needed to do access control on a subscription, and whether the
possibility of changes to configuration or access control policy may
render inadequate a strategy of evaluating the access decision function
only at the time the subscription is created.

Randy


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



From owner-netconf@ops.ietf.org Mon Apr 10 16:42:38 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FT3Da-0008Ls-2d
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 16:42:38 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FT3DY-0003g3-K0
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 16:42:38 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FT39p-0009wC-8D
	for netconf-data@psg.com; Mon, 10 Apr 2006 20:38: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.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.105] (helo=test-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <htrevino@cisco.com>)
	id 1FT39o-0009w1-Ii
	for netconf@ops.ietf.org; Mon, 10 Apr 2006 20:38:44 +0000
Received: from sj-core-5.cisco.com ([171.71.177.238])
  by test-iport-2.cisco.com with ESMTP; 10 Apr 2006 13:38:44 -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 k3AKcc7f000022;
	Mon, 10 Apr 2006 13:38:43 -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);
	 Mon, 10 Apr 2006 13:38:43 -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: architecture and security
Date: Mon, 10 Apr 2006 13:38:42 -0700
Message-ID: <6E21698722408147BEA594E073E2B0AB01A75BF8@xmb-sjc-223.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: architecture and security
Thread-Index: AcZZjfk3ThCtIQ0NQSyeI33YXaVlhgDSpqwA
From: "Hector Trevino \(htrevino\)" <htrevino@cisco.com>
To: "Andy Bierman" <ietf@andybierman.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 10 Apr 2006 20:38:43.0777 (UTC) FILETIME=[C23ADB10:01C65CDE]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a

=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Thursday, April 06, 2006 9:21 AM
> To: Netconf (E-mail)
> Subject: architecture and security
>=20
> Hi,
>=20
> I think the architecture for netconf notifications needs more=20
> attention.
> The current draft tries to fit notifications into the=20
> existing model for remote procedure calls.  The <rpc-one-way>=20
> is supposedly just like a regular <rpc>, except it goes from=20
> the agent to the manager, and there is no return value. =20
> Also, the WG decided (based on Junoscript experience) that=20
> returning <ok> was better than no return value -- we=20
> explicitly don't want a 1-way-rpc -- in either direction.
>=20
>=20
> There are 2 major problems with this architecture:
>=20
> 1) Headers are different becase the messages are different;
>    Notifications have different general characteristics
>    than RPC requests, so the headers will be different
>    (e.g., no timestamp in an RPC request like a notification)

HT: I'll comment in separate e-mail
>=20
> 2) Access control is backwards;
>    It doesn't make sense to apply access control to the '1 way RPC'
>    in the same sense as a regular RPC.  It is the manager who is
>    supposed to have access granted to view specific agent data -- not
>    the agent that is supposed to have access granted to
>    send the manager specific agent data.
>=20

HT: I agree w/the above but that's not the intention (yes, I know this
is not in the draft).=20
A manager has to have a subscription registered with the agent to
receive notifications. This can be done directly by the manager or by
some other means (e.g. manually on the device). You could explicitley
configure the subscription or reference some pre-defined profile.=20

Let's take case 1 above (i.e. manager creates a subscription) and add
the goal of leveraging existing NE security mechanisms. When a request
is issued (i.e. create subscription) the user's authorization is
validated (e.g. via external server or locally). The first level is to
determine whether or not the user is allowed to receive the type of
notifications which are being requested (e.g. config changes). At this
point, the request is accepted because a) the user is allowed to receive
all requested notifications or b) the user is allowed to receive a
subset but the agent applies an additional filter OR it is rejected
because the user is not allowed to receive all the requested
notification types. This IMO should be the base capability.=20

Some deployments will require additional granularity in which case going
down to the interface level should be sufficient. At least for
monitoring this allows partitioning the views/reception of notifications
and keeps down the administration burden.=20

=20

>=20
> Even though the term <rpc-one-way> is being removed, and the=20
> message will be called <notification> instead (as it is on=20
> page 17), we still need a secure architecture which scales=20
> well, and will support a user-based access control model.
> We need to think of how notifications fit into the base=20
> netconf protocol, as well as existing security and NM protocols.
> Operational issues and common use cases (e.g., building=20
> power-cycle) need to be addressed.
>=20
> Once the requirements and architecture are understood, we=20
> will be able to simplify and focus the API.  It isn't=20
> acceptable to come to the conclusion that a feature is a 95%=20
> lose-lose scenario, but we should do it anyway.
>=20
>=20
> 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 Mon Apr 10 17:04:01 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FT3YH-0006f8-Rs
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 17:04:01 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FT3YG-00049l-Ea
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 17:04:01 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FT3V1-000BNQ-2s
	for netconf-data@psg.com; Mon, 10 Apr 2006 21:00: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 1FT3Uz-000BN6-QR
	for netconf@ops.ietf.org; Mon, 10 Apr 2006 21:00:38 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 198B555DA3;
	Mon, 10 Apr 2006 23:00:37 +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 16366-04; Mon, 10 Apr 2006 23:00:35 +0200 (CEST)
Received: from boskop.local (unknown [10.222.1.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.iu-bremen.de (Postfix) with ESMTP id 325BB55D8C;
	Mon, 10 Apr 2006 23:00:35 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id 658696A2410; Mon, 10 Apr 2006 23:00:32 +0200 (CEST)
Date: Mon, 10 Apr 2006 23:00:32 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Randy Presuhn <randy_presuhn@mindspring.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: architecture and security
Message-ID: <20060410210032.GA5376@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Randy Presuhn <randy_presuhn@mindspring.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
References: <Pine.LNX.4.10.10604101126230.13053-100000@shell4.bayarea.net> <000801c65cd1$83f48c00$6401a8c0@oemcomputer> <20060410195239.GA4952@boskop.local> <001601c65cde$ee05f220$6401a8c0@oemcomputer>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001601c65cde$ee05f220$6401a8c0@oemcomputer>
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: 3e15cc4fdc61d7bce84032741d11c8e5

On Mon, Apr 10, 2006 at 01:39:56PM -0700, Randy Presuhn wrote:
> Hi -
> 
> > From: "Juergen Schoenwaelder" <j.schoenwaelder@iu-bremen.de>
> > To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> > Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
> > Sent: Monday, April 10, 2006 12:52 PM
> > Subject: Re: architecture and security
> ... 
> > I have recently looked at a different problem, namely the
> > anonymization (or pseudonymization) of management traffic and
> > configurations and it is virtually impossible to get this right since
> > information leaks through very easily (just consider an IPv6 address
> > derived from an IEEE MAC address which is then used to derive an
> > SnmpEngineID - and now your task is to anonymize the MAC address).
> > While it might be possible to get things right for a given device with
> > enough man-power for standard read-only tables (and I very much doubt
> > that someone is willing spending this money for a single device while
> > the next device means you have to repeat major parts of the exercise
> > due to many private MIB objects), things melt down quite quickly once
> > you face tables where users can name entries or even put descriptions
> > or other opaque things into an agent. Operationally useful names
> > usually carry quite a bit of context (this is exactly why they are
> > useful to operators) and so it is very likely that information leaks
> > through these descriptions.
> 
> No disagreement on this point, but I think it is quite a different one from
> the claim that VACM causes management information to become
> inconsistent.

Executive summary or my elaboration above:

    VACM rules either leak information (because it is too hard or even
    impossible to get them right) or they lead to inconsistencies
    (because they suppress information that should be available).

I do not agree that it is the manager's fault if it assumes certain
information to be available. Sure, a manager should detect cases where
information is missing and not go crazy. But then again, once you have
insufficient information, there is not much useful management one can
expect to happen.

I agree with you so far as that "inconsistent" might be the wrong term
- the term "incomplete" might better describe the situation.

/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 Mon Apr 10 17:54:57 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FT4LZ-0002cq-El
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 17:54:57 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FT4LZ-0006AN-0z
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 17:54:57 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FT4GU-000E2R-3h
	for netconf-data@psg.com; Mon, 10 Apr 2006 21:49: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.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.87] (helo=sj-iport-5.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <htrevino@cisco.com>)
	id 1FT4GT-000E2E-A4
	for netconf@ops.ietf.org; Mon, 10 Apr 2006 21:49:41 +0000
Received: from sj-core-3.cisco.com ([171.68.223.137])
  by sj-iport-5.cisco.com with ESMTP; 10 Apr 2006 14:49:42 -0700
X-IronPort-AV: i="4.04,109,1144047600"; 
   d="scan'208"; a="267806456:sNHT33046440"
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k3ALnZ1t012013;
	Mon, 10 Apr 2006 14:49:40 -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);
	 Mon, 10 Apr 2006 14:49: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: architecture and security
Date: Mon, 10 Apr 2006 14:49:35 -0700
Message-ID: <6E21698722408147BEA594E073E2B0AB01A75C6A@xmb-sjc-223.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: architecture and security
Thread-Index: AcZZjfk3ThCtIQ0NQSyeI33YXaVlhgDUNq9A
From: "Hector Trevino \(htrevino\)" <htrevino@cisco.com>
To: "Andy Bierman" <ietf@andybierman.com>,
        "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 10 Apr 2006 21:49:36.0692 (UTC) FILETIME=[A92A2F40:01C65CE8]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b

=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Thursday, April 06, 2006 9:21 AM
> To: Netconf (E-mail)
> Subject: architecture and security
>=20
> Hi,
>=20
> I think the architecture for netconf notifications needs more=20
> attention.
> The current draft tries to fit notifications into the=20
> existing model for remote procedure calls.  The <rpc-one-way>=20
> is supposedly just like a regular <rpc>, except it goes from=20
> the agent to the manager, and there is no return value. =20
> Also, the WG decided (based on Junoscript experience) that=20
> returning <ok> was better than no return value -- we=20
> explicitly don't want a 1-way-rpc -- in either direction.
>=20
>=20
> There are 2 major problems with this architecture:
>=20
> 1) Headers are different becase the messages are different;
>    Notifications have different general characteristics
>    than RPC requests, so the headers will be different
>    (e.g., no timestamp in an RPC request like a notification)

HT: I'd expect the messages, let's say event and edit-config to be
different, because as you point out they are different. The draft
separates the event contents into Header and Data to identify event type
independent/dependent fields. Maybe I'm wrong but I don't see the
NETCONF operations identifying a header.=20

Then we have the remote invocation (e.g. the RPC layer) where I agree,
all messages should be delivered in the same manner and hence have the
same headers. This is why the draft proposed the one-way-message -
preserves the architecture. I don't see an architecture problem but
rather a design choice preference. The issues that we have discussed
before and keep coming up:

1) RPC without a reply (The WG doesn't want RPCs w/o reply)=20
2) Notification w/and w/o acks -- I think this one there was agreement
to go w/o acks
3) Introduction of a endless RPC=20
=20
=20
>=20
> 2) Access control is backwards;
>    It doesn't make sense to apply access control to the '1 way RPC'
>    in the same sense as a regular RPC.  It is the manager who is
>    supposed to have access granted to view specific agent data -- not
>    the agent that is supposed to have access granted to
>    send the manager specific agent data.
>=20
>=20
> Even though the term <rpc-one-way> is being removed, and the=20
> message will be called <notification> instead (as it is on=20
> page 17), we still need a secure architecture which scales=20
> well, and will support a user-based access control model.
> We need to think of how notifications fit into the base=20
> netconf protocol, as well as existing security and NM protocols.
> Operational issues and common use cases (e.g., building=20
> power-cycle) need to be addressed.
>=20
> Once the requirements and architecture are understood, we=20
> will be able to simplify and focus the API.  It isn't=20
> acceptable to come to the conclusion that a feature is a 95%=20
> lose-lose scenario, but we should do it anyway.
>=20
>=20
> 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 Mon Apr 10 19:05:15 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FT5Rb-0008Va-Bu
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 19:05:15 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FT5Ra-0001G9-22
	for netconf-archive@lists.ietf.org; Mon, 10 Apr 2006 19:05:15 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FT5Ms-000I9s-Nd
	for netconf-data@psg.com; Mon, 10 Apr 2006 23:00: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.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1
Received: from [207.69.195.62] (helo=pop-altamira.atl.sa.earthlink.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <randy_presuhn@mindspring.com>)
	id 1FT5Mr-000I9V-GG
	for netconf@ops.ietf.org; Mon, 10 Apr 2006 23:00:22 +0000
Received: from h-68-166-189-141.snvacaid.dynamic.covad.net ([68.166.189.141] helo=oemcomputer)
	by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1FT5Mq-0005oY-00
	for netconf@ops.ietf.org; Mon, 10 Apr 2006 19:00:20 -0400
Message-ID: <002501c65cf3$0d46f440$6401a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
References: <Pine.LNX.4.10.10604101126230.13053-100000@shell4.bayarea.net> <000801c65cd1$83f48c00$6401a8c0@oemcomputer> <20060410195239.GA4952@boskop.local> <001601c65cde$ee05f220$6401a8c0@oemcomputer> <20060410210032.GA5376@boskop.local>
Subject: Re: architecture and security
Date: Mon, 10 Apr 2006 16:03:59 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

Hi -

> From: "Juergen Schoenwaelder" <j.schoenwaelder@iu-bremen.de>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
> Sent: Monday, April 10, 2006 2:00 PM
> Subject: Re: architecture and security
...
> I do not agree that it is the manager's fault if it assumes certain
> information to be available. Sure, a manager should detect cases where
> information is missing and not go crazy. But then again, once you have
> insufficient information, there is not much useful management one can
> expect to happen.
> 
> I agree with you so far as that "inconsistent" might be the wrong term
> - the term "incomplete" might better describe the situation.
...

Violent agreement.

Randy


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



From owner-netconf@ops.ietf.org Wed Apr 12 20:22:26 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FTpbO-0001Vr-Ma
	for netconf-archive@lists.ietf.org; Wed, 12 Apr 2006 20:22:26 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FTpbO-0006ok-BS
	for netconf-archive@lists.ietf.org; Wed, 12 Apr 2006 20:22:26 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FTpVF-0007Qq-Bw
	for netconf-data@psg.com; Thu, 13 Apr 2006 00:16: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 1FTpVD-0007Pz-W6
	for netconf@ops.ietf.org; Thu, 13 Apr 2006 00:16:04 +0000
Received: from mail.networksolutionsemail.com (omr3.mgt.bos.netsol.com [10.49.2.113] (may be forged))
	by ns-omrbm3.netsolmail.com (8.12.10/8.12.10) with SMTP id k3D0G2Hx008679
	for <netconf@ops.ietf.org>; Wed, 12 Apr 2006 20:16:02 -0400
Received: (qmail 3444 invoked by uid 78); 13 Apr 2006 00:16:02 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.113 with SMTP; 13 Apr 2006 00:16:02 -0000
Message-ID: <443D9837.8020700@andybierman.com>
Date: Wed, 12 Apr 2006 17:15:51 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Notification Requirements Consensus Points
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: 5a9a1bd6c2d06a21d748b7d0070ddcb8

Hi,

It is difficult to measure WG consensus.
It seems like no matter what the issue is,
there are about equal numbers of opinions on either side.

There seems to be consensus on these points:
 - Top level message is <notification> (rpc-one-way is out)
 - Separation of header and content-independent data is needed
 - Both the manager subscription model and traditional agent-configured
   notification generator model should be supported
 - The header should include some type of classification
   (e.g., event-class). 
 - The ability to filter (i.e., drop) notifications at the source
   based on event class and notification data content is needed. 
   Access control is impacted by this feature.
 - Named profiles (if kept) need to be fully specified in a
   standard read-create data model.
 - There is no limit on the length of the notification data
   (same as for RPC data)

There does not seem to be consensus on these points:
 - The specific role of notifications in the netconf protocol
   or whether a specific role is even needed
 - The use of a read-only instead of a read-create data model
   for notification generation parameters
 - The use of specialized RPCs instead of a standard data model
   to configure notification generation parameters
 - The need for named profiles (issue is irrelevant if read-create
   data model approach is used)
 - Multiple subscriptions per session are needed
 - RPC operations and notifications should be mixed on the same session
 - The specific list of event classes, or
   whether this document or IANA maintains the list, or
   whether we even need a list at all (i.e., just a string match).
 - The need for a modify-subscription feature
   (Note that this is implicitly supported by edit-config if a
   read-create data model is used)
 - The use of an endless-RPC model (which is only relevant if
   the WG decides mixed-mode sessions are not required)
 - The specific standard notifications (if any) that an agent
   must support



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 Apr 13 05:19:17 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FTxyv-0003Ds-M8
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 05:19:17 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FTxyt-0005bX-Oz
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 05:19:17 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FTxsN-000Co4-PF
	for netconf-data@psg.com; Thu, 13 Apr 2006 09:12:31 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,HTML_90_100,
	HTML_MESSAGE,RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.1
Received: from [61.144.161.54] (helo=huawei.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <liyan_77@huawei.com>)
	id 1FTxsJ-000Cnc-U7
	for netconf@ops.ietf.org; Thu, 13 Apr 2006 09:12:28 +0000
Received: from huawei.com (szxga02-in [172.24.2.6])
 by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar
 3 2004)) with ESMTP id <0IXN00LAUM63JA@szxga02-in.huawei.com> for
 netconf@ops.ietf.org; Thu, 13 Apr 2006 17:25:16 +0800 (CST)
Received: from huawei.com ([172.24.1.6])
 by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar
 3 2004)) with ESMTP id <0IXN00JL4M5SHH@szxga02-in.huawei.com> for
 netconf@ops.ietf.org; Thu, 13 Apr 2006 17:25:15 +0800 (CST)
Received: from l48181 ([10.110.114.146])
 by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar
 3 2004)) with ESMTPA id <0IXN00LRTM5INA@szxml02-in.huawei.com> for
 netconf@ops.ietf.org; Thu, 13 Apr 2006 17:25:02 +0800 (CST)
Date: Thu, 13 Apr 2006 17:11:03 +0800
From: =?gb2312?B?wO7R0g==?= <liyan_77@huawei.com>
Subject: The wrong title
To: netconf@ops.ietf.org
Message-id: <000001c65eda$33d77ec0$92726e0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: multipart/alternative;
 boundary="Boundary_(ID_C2HV9W8MYFf0w7g4LphVYA)"
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.7 (/)
X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606

This is a multi-part message in MIME format.

--Boundary_(ID_C2HV9W8MYFf0w7g4LphVYA)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable

Hi,

The title of draft-ietf-netconf-prot-12.txt is =A1=B0NETCONF =
Configuration
Protocol=A1=B1 now.

I think the =A1=B0Configuration=A1=B1 is duplicate. So it should be =
=A1=B0Network
Configuration Protocol=A1=B1.


--Boundary_(ID_C2HV9W8MYFf0w7g4LphVYA)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dgb2312">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:=CB=CE=CC=E5;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:=BA=DA=CC=E5;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:=BF=AC=CC=E5_GB2312;
	panose-1:2 1 6 9 3 1 1 1 1 1;}
@font-face
	{font-family:"\@=CB=CE=CC=E5";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"\@=BA=DA=CC=E5";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"\@=BF=AC=CC=E5_GB2312";
	panose-1:2 1 6 9 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	text-indent:21.0pt;
	line-height:150%;
	text-autospace:none;
	font-size:10.5pt;
	font-family:"Times New Roman";}
h1
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-align:justify;
	text-justify:inter-ideograph;
	text-indent:-21.6pt;
	page-break-after:avoid;
	font-size:16.0pt;
	font-family:Arial;}
h2
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:28.8pt;
	text-align:justify;
	text-justify:inter-ideograph;
	text-indent:-28.8pt;
	page-break-after:avoid;
	font-size:12.0pt;
	font-family:Arial;
	font-weight:normal;}
h3
	{margin-top:13.0pt;
	margin-right:0cm;
	margin-bottom:13.0pt;
	margin-left:36.0pt;
	text-align:justify;
	text-justify:inter-ideograph;
	text-indent:-36.0pt;
	line-height:173%;
	page-break-after:avoid;
	font-size:12.0pt;
	font-family:"Times New Roman";
	font-weight:normal;}
p.MsoHeader, li.MsoHeader, div.MsoHeader
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	layout-grid-mode:char;
	font-size:9.0pt;
	font-family:Arial;}
p.MsoFooter, li.MsoFooter, div.MsoFooter
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:9.0pt;
	font-family:Arial;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.a, li.a, div.a
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:54.45pt;
	margin-bottom:.0001pt;
	text-align:center;
	text-indent:-18.45pt;
	font-size:9.0pt;
	font-family:Arial;}
p.a0, li.a0, div.a0
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Arial;}
p.a1, li.a1, div.a1
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:center;
	font-size:10.5pt;
	font-family:Arial;
	font-weight:bold;}
p.a2, li.a2, div.a2
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:54.45pt;
	text-align:center;
	text-indent:-18.45pt;
	font-size:9.0pt;
	font-family:Arial;}
p.a3, li.a3, div.a3
	{margin-top:4.0pt;
	margin-right:0cm;
	margin-bottom:4.0pt;
	margin-left:0cm;
	text-align:center;
	line-height:150%;
	page-break-after:avoid;
	text-autospace:none;
	font-size:10.5pt;
	font-family:"Times New Roman";}
p.a4, li.a4, div.a4
	{margin-top:15.0pt;
	margin-right:0cm;
	margin-bottom:15.0pt;
	margin-left:0cm;
	text-align:center;
	line-height:150%;
	text-autospace:none;
	font-size:18.0pt;
	font-family:Arial;}
p.a5, li.a5, div.a5
	{margin:0cm;
	margin-bottom:.0001pt;
	line-height:150%;
	text-autospace:none;
	font-size:10.5pt;
	font-family:"Times New Roman";}
p.a6, li.a6, div.a6
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	line-height:150%;
	text-autospace:none;
	border:none;
	padding:0cm;
	font-size:9.0pt;
	font-family:Arial;}
p.a7, li.a7, div.a7
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	text-indent:18.0pt;
	line-height:150%;
	text-autospace:none;
	border:none;
	padding:0cm;
	font-size:9.0pt;
	font-family:Arial;}
p.a8, li.a8, div.a8
	{margin:0cm;
	margin-bottom:.0001pt;
	text-indent:21.0pt;
	line-height:150%;
	text-autospace:none;
	font-size:10.5pt;
	font-family:Arial;
	color:blue;
	font-style:italic;}
span.EmailStyle30
	{font-family:Arial;
	color:windowtext;}
 /* Page Definitions */
 @page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	layout-grid:15.6pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>

</head>

<body lang=3DZH-CN link=3Dblue vlink=3Dpurple =
style=3D'text-justify-trim:punctuation'>

<div class=3DSection1 style=3D'layout-grid:15.6pt'>

<p class=3DMsoNormal style=3D'text-indent:18.0pt'><font size=3D1 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:9.0pt;line-height:150%;font-family:Arial'>Hi,</span></=
font></p>

<p class=3DMsoNormal style=3D'text-indent:18.0pt'><font size=3D1 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:9.0pt;line-height:150%;font-family:Arial'>The title
of draft-ietf-netconf-prot-12.txt is =A1=B0NETCONF Configuration =
Protocol=A1=B1 now.</span></font></p>

<p class=3DMsoNormal style=3D'text-indent:18.0pt'><font size=3D1 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:9.0pt;line-height:150%;font-family:Arial'>I think the
=A1=B0Configuration=A1=B1 is duplicate. So it should be =A1=B0Network =
Configuration Protocol=A1=B1.</span></font></p>

</div>

</body>

</html>

--Boundary_(ID_C2HV9W8MYFf0w7g4LphVYA)--

--
to 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 Apr 13 09:26:00 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FU1pg-0000sW-D9
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 09:26:00 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FU1pf-0004rm-OW
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 09:26:00 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FU1lD-0003Lg-0q
	for netconf-data@psg.com; Thu, 13 Apr 2006 13:21: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.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 1FU1lB-0003LE-6r
	for netconf@ops.ietf.org; Thu, 13 Apr 2006 13:21:21 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0E9184F0003
	for <netconf@ops.ietf.org>; Thu, 13 Apr 2006 15:21:20 +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, 13 Apr 2006 15:21:19 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 13 Apr 2006 15:21:19 +0200
Message-ID: <443E504E.7040109@ericsson.com>
Date: Thu, 13 Apr 2006 15:21:18 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
Reply-To:  balazs.lengyel@ericsson.com
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: architecture and security
References: <B8C821F9E0675D44BFA994C28C0120E5E25089@antitop.jnpr.net> <008b01c65cc9$ceeda320$6401a8c0@oemcomputer>
In-Reply-To: <008b01c65cc9$ceeda320$6401a8c0@oemcomputer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Apr 2006 13:21:19.0296 (UTC) FILETIME=[268A1C00:01C65EFD]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1


>> From: "Kent Watsen" <kwatsen@juniper.net>
>> To: "Andy Bierman" <ietf@andybierman.com>
>> Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
>> Sent: Thursday, April 06, 2006 8:45 PM
>> Subject: RE: architecture and security
> ...
>> 1. When the subscription-request comes in, the system must authenticate
>> that the request only subscribes to events the client is authorized to
>> receive
>>
>> 2. However, when each notification is generated by the system, the
>> system only forwards it to the client if it already has a subscription
>> in place for that kind of event
>>
>> In case you think that I'm contradicting my earlier statement
>> "eliminates the system from having to apply filters to the responses",
>> what I meant to say is that it eliminates *access control* from having
>> to apply filters to the responses.  This is true since any notification
>> matching the subscription request, which was authorized, is also
>> implicitly authorized to be sent to the client
> ...
> 

Does this mean that access rights are only checked at subscription ?
What happens if the user successfully subscribes to all notifications
then later his access rights are restricted.
Shall we check at the change of access rights
whether his subscription is still OK and remove it if no ?
Otherwise his rights might be removed and he still receives notifications
as long as he himself does not change his subscription. This latter
case is I feel not satisfactory.
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 Apr 13 09:26:01 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FU1ph-0000st-8X
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 09:26:01 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FU1pf-0004rl-OV
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 09:26:01 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FU1jd-0003B8-FO
	for netconf-data@psg.com; Thu, 13 Apr 2006 13:19: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.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 1FU1jb-0003Aq-SJ
	for netconf@ops.ietf.org; Thu, 13 Apr 2006 13:19:44 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C595E4F003D
	for <netconf@ops.ietf.org>; Thu, 13 Apr 2006 15:19:42 +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, 13 Apr 2006 15:19:42 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 13 Apr 2006 15:19:41 +0200
Message-ID: <443E4FED.5080403@ericsson.com>
Date: Thu, 13 Apr 2006 15:19:41 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
Reply-To:  balazs.lengyel@ericsson.com
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: architecture and security
References: <Pine.LNX.4.10.10604101214000.13053-100000@shell4.bayarea.net>
In-Reply-To: <Pine.LNX.4.10.10604101214000.13053-100000@shell4.bayarea.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Apr 2006 13:19:41.0908 (UTC) FILETIME=[EC7DE140:01C65EFC]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

I feel this is a feature not a bug.
If you have fine grained access control
you must be prepared that you might not see all interfaces. The first number
you get is the number of all interfaces not the number of interfaces visible to user A.
Can you give another example ?

Balazs

David T. Perkins wrote:
> HI,
> 
> Consider ifNumber. If a device has, say, 4 interfaces,
> but only a single one allows access to management info,
> then it appears that the management info is incorrect,
> since ifNumber will be 4 but only one interface is
> in the table.
> If you go through all MIB modules and try to set up
> VACM so that a limited set of info is available, then
> you will most likely end up with a set of management
> info that is accessible that appears is coming
> from a broken SNMP agent. 
> 

--
to 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 Apr 13 09:27:20 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FU1qy-0000vZ-FL
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 09:27:20 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FU1qy-0004tp-2D
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 09:27:20 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FU1mA-0003Rs-1w
	for netconf-data@psg.com; Thu, 13 Apr 2006 13: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.62] (helo=mailgw4.ericsson.se)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <balazs.lengyel@ericsson.com>)
	id 1FU1m7-0003RV-4D
	for netconf@ops.ietf.org; Thu, 13 Apr 2006 13:22:19 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 573814F0001;
	Thu, 13 Apr 2006 15:22:18 +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, 13 Apr 2006 15:22:17 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 13 Apr 2006 15:22:17 +0200
Message-ID: <443E5089.6080807@ericsson.com>
Date: Thu, 13 Apr 2006 15:22:17 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
Reply-To:  balazs.lengyel@ericsson.com
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: architecture and security
References: <B8C821F9E0675D44BFA994C28C0120E5E25089@antitop.jnpr.net> <008b01c65cc9$ceeda320$6401a8c0@oemcomputer>
In-Reply-To: <008b01c65cc9$ceeda320$6401a8c0@oemcomputer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Apr 2006 13:22:17.0649 (UTC) FILETIME=[49521210:01C65EFD]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0

Defining access control on a resource level is a
requirement for Ericsson. This still has two cases:
1) Managed Object type or class based: User A has access
to interfaces but not to routing information, while
user B can only access routing but not interfaces
2) Managed Object instance based: User A can access
IF=eth0 but not IF=eth1 while User B can access
IF=eth1 but not IF=eth0.

Both cases are required for us. Netconf should at
least not make it impossible to implement this.
Balazs

Randy Presuhn wrote:
> Hi -
> 
>> From: "Kent Watsen" <kwatsen@juniper.net>
>> To: "Andy Bierman" <ietf@andybierman.com>
>> Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
>> Sent: Thursday, April 06, 2006 8:45 PM
>> Subject: RE: architecture and security
> ...
>> 1. When the subscription-request comes in, the system must authenticate
>> that the request only subscribes to events the client is authorized to
>> receive
>>
>> 2. However, when each notification is generated by the system, the
>> system only forwards it to the client if it already has a subscription
>> in place for that kind of event
>>
>> In case you think that I'm contradicting my earlier statement
>> "eliminates the system from having to apply filters to the responses",
>> what I meant to say is that it eliminates *access control* from having
>> to apply filters to the responses.  This is true since any notification
>> matching the subscription request, which was authorized, is also
>> implicitly authorized to be sent to the client
> ...
> 
> It sounds like these access control policies are only in terms
> of the event type, and not in terms of the specific resources
> being managed.  In other words, if Customer A should only
> be able to access interface (a) configuration data,
> and Customer B should only be able to access interface (b),
> and the same event type is defined for both interfaces,
> we'd have a problem.
> 
> Or is this simply one of those things netconf won't support?
> 
> Randy
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <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 Apr 13 09:54:09 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FU2Gv-0007CF-Gu
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 09:54:09 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FU2Gv-0005Qt-1a
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 09:54:09 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FU2Bu-0005a6-AC
	for netconf-data@psg.com; Thu, 13 Apr 2006 13:48: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,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 1FU2Bt-0005Zv-M1
	for netconf@ops.ietf.org; Thu, 13 Apr 2006 13:48:57 +0000
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BB2554F0001
	for <netconf@ops.ietf.org>; Thu, 13 Apr 2006 15:47: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, 13 Apr 2006 15:47: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, 13 Apr 2006 15:47:34 +0200
Message-ID: <443E5676.10308@ericsson.com>
Date: Thu, 13 Apr 2006 15:47:34 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: architecture and security
References: <6E21698722408147BEA594E073E2B0AB01A75BF8@xmb-sjc-223.amer.cisco.com>
In-Reply-To: <6E21698722408147BEA594E073E2B0AB01A75BF8@xmb-sjc-223.amer.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Apr 2006 13:47:34.0907 (UTC) FILETIME=[D1AD44B0:01C65F00]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8

Yes some deployments will require additional granularity for access control. But different 
node types might have very different requirements about the fine granularity. Interface 
level might be good for you but I might want to have subscriber management separated from 
the rest of the data or might want the possibility to authorize each virtual router 
separately.

My point is that while granular access control is needed the standard should not try to 
define the levels of access control.

Balazs

Hector Trevino (htrevino) wrote:

> Some deployments will require additional granularity in which case going
> down to the interface level should be sufficient. 

--
to 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 Apr 13 10:25:23 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FU2l9-00065I-Ia
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 10:25:23 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FU2l8-0006OD-91
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 10:25:23 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FU2gH-0007ze-Bm
	for netconf-data@psg.com; Thu, 13 Apr 2006 14:20: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.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FU2gG-0007zA-Au
	for netconf@ops.ietf.org; Thu, 13 Apr 2006 14:20:20 +0000
Received: from mail.networksolutionsemail.com (omr5.mgt.bos.netsol.com [10.49.2.115] (may be forged))
	by ns-omrbm5.netsolmail.com (8.12.10/8.12.10) with SMTP id k3DEKI4F012473
	for <netconf@ops.ietf.org>; Thu, 13 Apr 2006 10:20:19 -0400
Received: (qmail 20506 invoked by uid 78); 13 Apr 2006 14:20:18 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.115 with SMTP; 13 Apr 2006 14:20:18 -0000
Message-ID: <443E5E19.1080203@andybierman.com>
Date: Thu, 13 Apr 2006 07:20:09 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: architecture and security
References: <6E21698722408147BEA594E073E2B0AB01A75BF8@xmb-sjc-223.amer.cisco.com> <443E5676.10308@ericsson.com>
In-Reply-To: <443E5676.10308@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: c1c65599517f9ac32519d043c37c5336

Balazs Lengyel wrote:
> Yes some deployments will require additional granularity for access 
> control. But different node types might have very different requirements 
> about the fine granularity. Interface level might be good for you but I 
> might want to have subscriber management separated from the rest of the 
> data or might want the possibility to authorize each virtual router 
> separately.
> 
> My point is that while granular access control is needed the standard 
> should not try to define the levels of access control.
> 

I disagree.
We have gone pretty far along now ignoring access control.
IMO, applying access control on the subscription, but not
the outbound notifications, is just broken.

The config data is dynamic, the access rights database is dynamic.
What matters is the receivers access rights at the time
the notification is sent, not when the subscription is made.

I don't think we have to define a detailed model now,
but we have agree when and where access control is applied.

> Balazs

Andy


> 
> Hector Trevino (htrevino) wrote:
> 
>> Some deployments will require additional granularity in which case going
>> down to the interface level should be sufficient. 
> 
> -- 
> to 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 Apr 13 10:48:48 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FU37o-0003Po-Fo
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 10:48:48 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FU37o-0007KN-3M
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 10:48:48 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FU33h-0009kO-Ep
	for netconf-data@psg.com; Thu, 13 Apr 2006 14:44:33 +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,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 1FU33g-0009k5-46
	for netconf@ops.ietf.org; Thu, 13 Apr 2006 14:44:32 +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 k3DEiPL17086
	for <netconf@ops.ietf.org>; Thu, 13 Apr 2006 10:44:26 -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: Notification Requirements Consensus Points
Date: Thu, 13 Apr 2006 10:44:15 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B407E35820@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notification Requirements Consensus Points
Thread-Index: AcZekHjY/CvCpREpT4OewXAwUT/qxAAd3MlA
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

I still don't agree with the first bullet, but if I am the only one who
worries about the ramifications of this layer compression, I can yield
in the effort to move forward.

What we (the editor's) would like to do is create an update to the
document based on the consensus points for next week or, if the long
weekend here delays us, very early the next.

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Wednesday, April 12, 2006 8:16 PM
To: Netconf (E-mail)
Subject: Notification Requirements Consensus Points


Hi,

It is difficult to measure WG consensus.
It seems like no matter what the issue is,
there are about equal numbers of opinions on either side.

There seems to be consensus on these points:
 - Top level message is <notification> (rpc-one-way is out)
 - Separation of header and content-independent data is needed
 - Both the manager subscription model and traditional agent-configured
   notification generator model should be supported
 - The header should include some type of classification
   (e.g., event-class).=20
 - The ability to filter (i.e., drop) notifications at the source
   based on event class and notification data content is needed.=20
   Access control is impacted by this feature.
 - Named profiles (if kept) need to be fully specified in a
   standard read-create data model.
 - There is no limit on the length of the notification data
   (same as for RPC data)

There does not seem to be consensus on these points:
 - The specific role of notifications in the netconf protocol
   or whether a specific role is even needed
 - The use of a read-only instead of a read-create data model
   for notification generation parameters
 - The use of specialized RPCs instead of a standard data model
   to configure notification generation parameters
 - The need for named profiles (issue is irrelevant if read-create
   data model approach is used)
 - Multiple subscriptions per session are needed
 - RPC operations and notifications should be mixed on the same session
 - The specific list of event classes, or
   whether this document or IANA maintains the list, or
   whether we even need a list at all (i.e., just a string match).
 - The need for a modify-subscription feature
   (Note that this is implicitly supported by edit-config if a
   read-create data model is used)
 - The use of an endless-RPC model (which is only relevant if
   the WG decides mixed-mode sessions are not required)
 - The specific standard notifications (if any) that an agent
   must support



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 Thu Apr 13 11:18:09 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FU3aD-0000o5-4K
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 11:18:09 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FU3aC-0008SU-OO
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 11:18:09 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FU3UR-000BqQ-MR
	for netconf-data@psg.com; Thu, 13 Apr 2006 15:12: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=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 1FU3UR-000Bq4-0N
	for netconf@ops.ietf.org; Thu, 13 Apr 2006 15:12:11 +0000
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k3DFC1qt004857;
	Thu, 13 Apr 2006 08:12:01 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k3DFC1MV004852;
	Thu, 13 Apr 2006 08:12:01 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Thu, 13 Apr 2006 08:12:00 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
cc: Randy Presuhn <randy_presuhn@mindspring.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: architecture and security
In-Reply-To: <443E5089.6080807@ericsson.com>
Message-ID: <Pine.LNX.4.10.10604130809500.2749-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: 0fa76816851382eb71b0a882ccdc29ac

HI,

Can you describe the problem that you are trying to
solve (instead of TELLing us THE solution). And have
you looked at other solutions, and if so, would
you describe the pros and cons of each.

Regards,
/david t. perkins
On Thu, 13 Apr 2006, Balazs Lengyel wrote:
> Defining access control on a resource level is a
> requirement for Ericsson. This still has two cases:
> 1) Managed Object type or class based: User A has access
> to interfaces but not to routing information, while
> user B can only access routing but not interfaces
> 2) Managed Object instance based: User A can access
> IF=eth0 but not IF=eth1 while User B can access
> IF=eth1 but not IF=eth0.
> 
> Both cases are required for us. Netconf should at
> least not make it impossible to implement this.
> Balazs
> 
> Randy Presuhn wrote:
> > Hi -
> > 
> >> From: "Kent Watsen" <kwatsen@juniper.net>
> >> To: "Andy Bierman" <ietf@andybierman.com>
> >> Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
> >> Sent: Thursday, April 06, 2006 8:45 PM
> >> Subject: RE: architecture and security
> > ...
> >> 1. When the subscription-request comes in, the system must authenticate
> >> that the request only subscribes to events the client is authorized to
> >> receive
> >>
> >> 2. However, when each notification is generated by the system, the
> >> system only forwards it to the client if it already has a subscription
> >> in place for that kind of event
> >>
> >> In case you think that I'm contradicting my earlier statement
> >> "eliminates the system from having to apply filters to the responses",
> >> what I meant to say is that it eliminates *access control* from having
> >> to apply filters to the responses.  This is true since any notification
> >> matching the subscription request, which was authorized, is also
> >> implicitly authorized to be sent to the client
> > ...
> > 
> > It sounds like these access control policies are only in terms
> > of the event type, and not in terms of the specific resources
> > being managed.  In other words, if Customer A should only
> > be able to access interface (a) configuration data,
> > and Customer B should only be able to access interface (b),
> > and the same event type is defined for both interfaces,
> > we'd have a problem.
> > 
> > Or is this simply one of those things netconf won't support?
> > 
> > Randy
> > 
> > 
> > --
> > to unsubscribe send a message to netconf-request@ops.ietf.org with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <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 Apr 13 12:31:41 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FU4jN-0001VP-AF
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 12:31:41 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FU4jM-0002WA-Rl
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 12:31:41 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FU4fY-000HPE-0O
	for netconf-data@psg.com; Thu, 13 Apr 2006 16:27: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.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FU4fW-000HP1-Mr
	for netconf@ops.ietf.org; Thu, 13 Apr 2006 16:27:43 +0000
Received: from mail.networksolutionsemail.com (omr2.mgt.bos.netsol.com [10.49.2.112] (may be forged))
	by ns-omrbm2.netsolmail.com (8.12.10/8.12.10) with SMTP id k3DGRfvW029683
	for <netconf@ops.ietf.org>; Thu, 13 Apr 2006 12:27:41 -0400
Received: (qmail 16606 invoked by uid 78); 13 Apr 2006 16:27:40 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.112 with SMTP; 13 Apr 2006 16:27:40 -0000
Message-ID: <443E7BF5.3010905@andybierman.com>
Date: Thu, 13 Apr 2006 09:27:33 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "David T. Perkins" <dperkins@dsperkins.com>
CC: Balazs Lengyel <balazs.lengyel@ericsson.com>,
        Randy Presuhn <randy_presuhn@mindspring.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: architecture and security
References: <Pine.LNX.4.10.10604130809500.2749-100000@shell4.bayarea.net>
In-Reply-To: <Pine.LNX.4.10.10604130809500.2749-100000@shell4.bayarea.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: b22590c27682ace61775ee7b453b40d3

David T. Perkins wrote:
> HI,
> 
> Can you describe the problem that you are trying to
> solve (instead of TELLing us THE solution). And have
> you looked at other solutions, and if so, would
> you describe the pros and cons of each.

I think both examples below make sense.

Access by feature classification regardless of XML subtree
location is useful.  This can also be done by locating
related features under a common parent node, but often NE features
have some config data spread out all over the XML tree.
(Some global, per-interface, per-circuit, etc.)

I don't think 'interfaces' is granular enough, or an appropriate feature
category.

A config might look like:

<acme>
   <feature-A> ...
   <feature-B> ...
   <interfaces>
      <interface>
         <name>eth0</name>
         <feature-A> ...
         <feature-C> ...
      </interface>
   </interface>
</acme>

Access to all 'interfaces' in this model doesn't make much sense.
Access to all of 'feature-A' regardless of where the XML is located
makes sense.  Common namespace usage makes this easy.

I also want to point out that nobody is asking for instance granularity
within a row.  People have asked for "user A can look at all instances
of the foo object" or "user B can look at all the data in row X of
the interfaces table".  This is very different than VACM (and much
simpler/better IMO), where the columns in an individual row can have
different access control rights for every user.


> 
> Regards,
> /david t. perkins

Andy


> On Thu, 13 Apr 2006, Balazs Lengyel wrote:
>> Defining access control on a resource level is a
>> requirement for Ericsson. This still has two cases:
>> 1) Managed Object type or class based: User A has access
>> to interfaces but not to routing information, while
>> user B can only access routing but not interfaces
>> 2) Managed Object instance based: User A can access
>> IF=eth0 but not IF=eth1 while User B can access
>> IF=eth1 but not IF=eth0.
>>
>> Both cases are required for us. Netconf should at
>> least not make it impossible to implement this.
>> Balazs
>>
>> Randy Presuhn wrote:
>>> Hi -
>>>
>>>> From: "Kent Watsen" <kwatsen@juniper.net>
>>>> To: "Andy Bierman" <ietf@andybierman.com>
>>>> Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
>>>> Sent: Thursday, April 06, 2006 8:45 PM
>>>> Subject: RE: architecture and security
>>> ...
>>>> 1. When the subscription-request comes in, the system must authenticate
>>>> that the request only subscribes to events the client is authorized to
>>>> receive
>>>>
>>>> 2. However, when each notification is generated by the system, the
>>>> system only forwards it to the client if it already has a subscription
>>>> in place for that kind of event
>>>>
>>>> In case you think that I'm contradicting my earlier statement
>>>> "eliminates the system from having to apply filters to the responses",
>>>> what I meant to say is that it eliminates *access control* from having
>>>> to apply filters to the responses.  This is true since any notification
>>>> matching the subscription request, which was authorized, is also
>>>> implicitly authorized to be sent to the client
>>> ...
>>>
>>> It sounds like these access control policies are only in terms
>>> of the event type, and not in terms of the specific resources
>>> being managed.  In other words, if Customer A should only
>>> be able to access interface (a) configuration data,
>>> and Customer B should only be able to access interface (b),
>>> and the same event type is defined for both interfaces,
>>> we'd have a problem.
>>>
>>> Or is this simply one of those things netconf won't support?
>>>
>>> Randy
>>>
>>>
>>> --
>>> to unsubscribe send a message to netconf-request@ops.ietf.org with
>>> the word 'unsubscribe' in a single line as the message text body.
>>> archive: <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 Thu Apr 13 14:27:04 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FU6X2-0004zg-FI
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 14:27:04 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FU6X0-0006Sy-SI
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 14:27:04 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FU6S7-000OjL-FC
	for netconf-data@psg.com; Thu, 13 Apr 2006 18:21:59 +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 1FU6S5-000Oj8-IY
	for netconf@ops.ietf.org; Thu, 13 Apr 2006 18:21:57 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 7CE5655E1A;
	Thu, 13 Apr 2006 20:21: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 08983-05; Thu, 13 Apr 2006 20:21:54 +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 B359E55DCB;
	Thu, 13 Apr 2006 20:21:54 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id E071F6A47D8; Thu, 13 Apr 2006 20:21:52 +0200 (CEST)
Date: Thu, 13 Apr 2006 20:21:52 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Andy Bierman <ietf@andybierman.com>
Cc: "David T. Perkins" <dperkins@dsperkins.com>,
	Balazs Lengyel <balazs.lengyel@ericsson.com>,
	Randy Presuhn <randy_presuhn@mindspring.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: architecture and security
Message-ID: <20060413182152.GC1076@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Andy Bierman <ietf@andybierman.com>,
	"David T. Perkins" <dperkins@dsperkins.com>,
	Balazs Lengyel <balazs.lengyel@ericsson.com>,
	Randy Presuhn <randy_presuhn@mindspring.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
References: <Pine.LNX.4.10.10604130809500.2749-100000@shell4.bayarea.net> <443E7BF5.3010905@andybierman.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <443E7BF5.3010905@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: b19722fc8d3865b147c75ae2495625f2

On Thu, Apr 13, 2006 at 09:27:33AM -0700, Andy Bierman wrote:
 
> I also want to point out that nobody is asking for instance granularity
> within a row.  People have asked for "user A can look at all instances
> of the foo object" or "user B can look at all the data in row X of
> the interfaces table".  This is very different than VACM (and much
> simpler/better IMO), where the columns in an individual row can have
> different access control rights for every user.

Still, the hard problem are references to things under access control.
Some boxes to maintain fault history tables that may refer to
interfaces (or to physical ports that are related to interfaces). How
will the access control model deal with such cases?

Of course, fault history data is not config data so you can take the
formal position that this example is out of scope for netconf access
control. But I think the question of how to deal with references will
remain and this is especially nasty if references are embedded into
identifiers.

Note that I am not asking for a complex solution - I just believe we
should be very clear what an access control model can do and what not.

/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 Apr 13 15:21:32 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FU7Nk-0000fb-L9
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 15:21:32 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FU7Nj-0007z7-BG
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 15:21:32 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FU7Im-0002Eu-NZ
	for netconf-data@psg.com; Thu, 13 Apr 2006 19:16: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.5 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [205.178.146.50] (helo=omr1.networksolutionsemail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FU7Il-0002Eg-MP
	for netconf@ops.ietf.org; Thu, 13 Apr 2006 19:16:23 +0000
Received: from mail.networksolutionsemail.com (omr1.mgt.bos.netsol.com [10.49.2.111] (may be forged))
	by omr1.networksolutionsemail.com (8.12.10/8.12.10) with SMTP id k3DJGMZj010942
	for <netconf@ops.ietf.org>; Thu, 13 Apr 2006 15:16:22 -0400
Received: (qmail 26273 invoked by uid 78); 13 Apr 2006 19:16:21 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.111 with SMTP; 13 Apr 2006 19:16:21 -0000
Message-ID: <443EA37E.20908@andybierman.com>
Date: Thu, 13 Apr 2006 12:16:14 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>,
        "David T. Perkins" <dperkins@dsperkins.com>,
        Balazs Lengyel <balazs.lengyel@ericsson.com>,
        Randy Presuhn <randy_presuhn@mindspring.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: architecture and security
References: <Pine.LNX.4.10.10604130809500.2749-100000@shell4.bayarea.net> <443E7BF5.3010905@andybierman.com> <20060413182152.GC1076@boskop.local>
In-Reply-To: <20060413182152.GC1076@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: 9ed51c9d1356100bce94f1ae4ec616a9

Juergen Schoenwaelder wrote:
> On Thu, Apr 13, 2006 at 09:27:33AM -0700, Andy Bierman wrote:
>  
>> I also want to point out that nobody is asking for instance granularity
>> within a row.  People have asked for "user A can look at all instances
>> of the foo object" or "user B can look at all the data in row X of
>> the interfaces table".  This is very different than VACM (and much
>> simpler/better IMO), where the columns in an individual row can have
>> different access control rights for every user.
> 
> Still, the hard problem are references to things under access control.
> Some boxes to maintain fault history tables that may refer to
> interfaces (or to physical ports that are related to interfaces). How
> will the access control model deal with such cases?
> 
> Of course, fault history data is not config data so you can take the
> formal position that this example is out of scope for netconf access
> control. But I think the question of how to deal with references will
> remain and this is especially nasty if references are embedded into
> identifiers.

References in identifiers -- you mean like information
carried in the instance portion of an OID?

Not sure what you mean

> 
> Note that I am not asking for a complex solution - I just believe we
> should be very clear what an access control model can do and what not.
> 

Agreed.


> /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 Apr 13 15:29:27 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FU7VP-0006Y4-Jx
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 15:29:27 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FU7VO-0008Fj-A4
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 15:29:27 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FU7SH-0002s5-Q3
	for netconf-data@psg.com; Thu, 13 Apr 2006 19:26: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 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 1FU7SG-0002rr-Od
	for netconf@ops.ietf.org; Thu, 13 Apr 2006 19:26:12 +0000
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32])
	by hermes.iu-bremen.de (Postfix) with ESMTP id 0D52F55D10;
	Thu, 13 Apr 2006 21:26:12 +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 13594-03; Thu, 13 Apr 2006 21:26:10 +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 5004355CE0;
	Thu, 13 Apr 2006 21:26:10 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501)
	id A07FE6A4929; Thu, 13 Apr 2006 21:26:08 +0200 (CEST)
Date: Thu, 13 Apr 2006 21:26:08 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Andy Bierman <ietf@andybierman.com>
Cc: "David T. Perkins" <dperkins@dsperkins.com>,
	Balazs Lengyel <balazs.lengyel@ericsson.com>,
	Randy Presuhn <randy_presuhn@mindspring.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: architecture and security
Message-ID: <20060413192608.GA1461@boskop.local>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: Andy Bierman <ietf@andybierman.com>,
	"David T. Perkins" <dperkins@dsperkins.com>,
	Balazs Lengyel <balazs.lengyel@ericsson.com>,
	Randy Presuhn <randy_presuhn@mindspring.com>,
	"Netconf (E-mail)" <netconf@ops.ietf.org>
References: <Pine.LNX.4.10.10604130809500.2749-100000@shell4.bayarea.net> <443E7BF5.3010905@andybierman.com> <20060413182152.GC1076@boskop.local> <443EA37E.20908@andybierman.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <443EA37E.20908@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: 93238566e09e6e262849b4f805833007

On Thu, Apr 13, 2006 at 12:16:14PM -0700, Andy Bierman wrote:
 
> References in identifiers -- you mean like information
> carried in the instance portion of an OID?
> 
> Not sure what you mean

Operators seem to like to name things in meaningful ways and these
names frequently carry information which may be sensitive. If you want
to define views so that different people can look at a box, you have
to ensure that nothing leaks through which might be embedded in
operator assigned names (and thus can't be really handled by access
control rules unless you have embedded AI).

/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 Apr 13 19:39:07 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FUBP1-00022M-HW
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 19:39:07 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FUBP0-0000kl-Vv
	for netconf-archive@lists.ietf.org; Thu, 13 Apr 2006 19:39:07 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FUBJS-000Ful-8g
	for netconf-data@psg.com; Thu, 13 Apr 2006 23:33: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.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FUBJP-000Fua-DJ
	for netconf@ops.ietf.org; Thu, 13 Apr 2006 23:33:19 +0000
Received: from mail.networksolutionsemail.com (omr5.mgt.bos.netsol.com [10.49.2.115] (may be forged))
	by ns-omrbm5.netsolmail.com (8.12.10/8.12.10) with SMTP id k3DNXH4F017688
	for <netconf@ops.ietf.org>; Thu, 13 Apr 2006 19:33:18 -0400
Received: (qmail 17151 invoked by uid 78); 13 Apr 2006 23:33:17 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.115 with SMTP; 13 Apr 2006 23:33:17 -0000
Message-ID: <443EDFB4.7080906@andybierman.com>
Date: Thu, 13 Apr 2006 16:33:08 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Requirements Consensus Points
References: <713043CE8B8E1348AF3C546DBE02C1B407E35820@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B407E35820@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: 1676547e4f33b5e63227e9c02bd359e3

Sharon Chisholm wrote:
> hi
> 
> I still don't agree with the first bullet, but if I am the only one who
> worries about the ramifications of this layer compression, I can yield
> in the effort to move forward.

Good.

It isn't a matter of layer compression.
It may very well be useful for somebody to
have the agent make an actual RPC call to the manager.
In this case, the current RPC model works, with
access control going in the right direction
(agent getting permission to do something on the manager).

A notification (from agent to manager) is an entirely
different mechanism.  The access control is granted
to the manager to view specific data from the agent.
A notification carries no 'responsibilities'
or side effects on the manager whatsoever (unlike an
RPC request from agent to manager).  The agent is
just responsible for delivering the data and the manager
can simply drop the notification if it wants.

IMO, this makes it very different than a reverse-RPC.


> 
> What we (the editor's) would like to do is create an update to the
> document based on the consensus points for next week or, if the long
> weekend here delays us, very early the next.

Great

> 
> Sharon

Andy

> 
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
> Behalf Of Andy Bierman
> Sent: Wednesday, April 12, 2006 8:16 PM
> To: Netconf (E-mail)
> Subject: Notification Requirements Consensus Points
> 
> 
> Hi,
> 
> It is difficult to measure WG consensus.
> It seems like no matter what the issue is,
> there are about equal numbers of opinions on either side.
> 
> There seems to be consensus on these points:
>  - Top level message is <notification> (rpc-one-way is out)
>  - Separation of header and content-independent data is needed
>  - Both the manager subscription model and traditional agent-configured
>    notification generator model should be supported
>  - The header should include some type of classification
>    (e.g., event-class). 
>  - The ability to filter (i.e., drop) notifications at the source
>    based on event class and notification data content is needed. 
>    Access control is impacted by this feature.
>  - Named profiles (if kept) need to be fully specified in a
>    standard read-create data model.
>  - There is no limit on the length of the notification data
>    (same as for RPC data)
> 
> There does not seem to be consensus on these points:
>  - The specific role of notifications in the netconf protocol
>    or whether a specific role is even needed
>  - The use of a read-only instead of a read-create data model
>    for notification generation parameters
>  - The use of specialized RPCs instead of a standard data model
>    to configure notification generation parameters
>  - The need for named profiles (issue is irrelevant if read-create
>    data model approach is used)
>  - Multiple subscriptions per session are needed
>  - RPC operations and notifications should be mixed on the same session
>  - The specific list of event classes, or
>    whether this document or IANA maintains the list, or
>    whether we even need a list at all (i.e., just a string match).
>  - The need for a modify-subscription feature
>    (Note that this is implicitly supported by edit-config if a
>    read-create data model is used)
>  - The use of an endless-RPC model (which is only relevant if
>    the WG decides mixed-mode sessions are not required)
>  - The specific standard notifications (if any) that an agent
>    must support
> 
> 
> 
> 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 Fri Apr 14 05:20:10 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FUKTK-0003en-UO
	for netconf-archive@lists.ietf.org; Fri, 14 Apr 2006 05:20:10 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FUKTK-0002bQ-BC
	for netconf-archive@lists.ietf.org; Fri, 14 Apr 2006 05:20:10 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FUKO5-000Kvo-4g
	for netconf-data@psg.com; Fri, 14 Apr 2006 09:14: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.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 1FUKO3-000KvZ-7i
	for netconf@ops.ietf.org; Fri, 14 Apr 2006 09:14:43 +0000
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0EBAD4F0001
	for <netconf@ops.ietf.org>; Fri, 14 Apr 2006 11:14:42 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 14 Apr 2006 11:14:41 +0200
Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 14 Apr 2006 11:14:41 +0200
Message-ID: <443F6800.7030501@ericsson.com>
Date: Fri, 14 Apr 2006 11:14:40 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: architecture and security
References: <Pine.LNX.4.10.10604130809500.2749-100000@shell4.bayarea.net> <443E7BF5.3010905@andybierman.com> <20060413182152.GC1076@boskop.local> <443EA37E.20908@andybierman.com> <20060413192608.GA1461@boskop.local>
In-Reply-To: <20060413192608.GA1461@boskop.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Apr 2006 09:14:41.0289 (UTC) FILETIME=[DCA72F90:01C65FA3]
X-Brightmail-Tracker: AAAAAA==
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336

I have to say that my requirements (coming from telecom operators) do ask for some 
complicated cases.

I need to handle the following two cases:
1) A router with multiple virtual routers. Each virtual router might be managed by a 
separate organization. This would mean that a subtree of the data model must be assigned 
to each organization.
2) I have a big box: where user A is responsible for configuration management while user B 
is responsible for performance management. I want to keep them separate. This would mean 
that some type of objects (representing performance measurements) should be handled 
separately.

Information leaks can't be fully avoided but with careful modeling of data and 
documentation warning about the possibility of some leaks we can provide a solution that 
is better then just saying NO.

All I am asking for that Netconf should not actively prohibit such a solution.
Balazs

Juergen Schoenwaelder wrote:
> On Thu, Apr 13, 2006 at 12:16:14PM -0700, Andy Bierman wrote:
>  
>> References in identifiers -- you mean like information
>> carried in the instance portion of an OID?
>>
>> Not sure what you mean
> 
> Operators seem to like to name things in meaningful ways and these
> names frequently carry information which may be sensitive. If you want
> to define views so that different people can look at a box, you have
> to ensure that nothing leaks through which might be embedded in
> operator assigned names (and thus can't be really handled by access
> control rules unless you have embedded AI).
> 
> /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 Fri Apr 14 11:27:10 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FUQCU-00013F-7C
	for netconf-archive@lists.ietf.org; Fri, 14 Apr 2006 11:27:10 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FUQCR-0005CC-LP
	for netconf-archive@lists.ietf.org; Fri, 14 Apr 2006 11:27:08 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FUQ6n-000Kkn-Ak
	for netconf-data@psg.com; Fri, 14 Apr 2006 15:21: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 1FUQ6k-000KkY-98
	for netconf@ops.ietf.org; Fri, 14 Apr 2006 15:21:14 +0000
Received: from mail.networksolutionsemail.com (omr5.mgt.bos.netsol.com [10.49.2.115] (may be forged))
	by ns-omrbm5.netsolmail.com (8.12.10/8.12.10) with SMTP id k3EFKr4F029182
	for <netconf@ops.ietf.org>; Fri, 14 Apr 2006 11:21:09 -0400
Received: (qmail 13474 invoked by uid 78); 14 Apr 2006 15:20:51 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.115 with SMTP; 14 Apr 2006 15:20:51 -0000
Message-ID: <443FBDC7.9040006@andybierman.com>
Date: Fri, 14 Apr 2006 08:20:39 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: architecture and security
References: <Pine.LNX.4.10.10604130809500.2749-100000@shell4.bayarea.net> <443E7BF5.3010905@andybierman.com> <20060413182152.GC1076@boskop.local> <443EA37E.20908@andybierman.com> <20060413192608.GA1461@boskop.local> <443F6800.7030501@ericsson.com>
In-Reply-To: <443F6800.7030501@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: 31247fb3be228bb596db9127becad0bc

Balazs Lengyel wrote:
> I have to say that my requirements (coming from telecom operators) do 
> ask for some complicated cases.
> 
> I need to handle the following two cases:
> 1) A router with multiple virtual routers. Each virtual router might be 
> managed by a separate organization. This would mean that a subtree of 
> the data model must be assigned to each organization.
> 2) I have a big box: where user A is responsible for configuration 
> management while user B is responsible for performance management. I 
> want to keep them separate. This would mean that some type of objects 
> (representing performance measurements) should be handled separately.
> 


You can embed classification in the schema, or in the
XML tree itself, in elements or attributes.
You can use namespaces.  Access control in XML
shouldn't be that hard.


> Information leaks can't be fully avoided but with careful modeling of 
> data and documentation warning about the possibility of some leaks we 
> can provide a solution that is better then just saying NO.
> 


We are not likely to solve the rmonAlarmVariable (object shadowing)
problem with netconf access control.  Since naming and data components
are treated the same in XML (unlike SMI OIDs) there is no need
to worry about the name of an instance leaking information,
but history buffers, variable-pointers, data embedded in
show command printfs, can all leak information.  We aren't
going to rid the world of these dangers.
Security considerations sections are there to be read
(no, really, it's not all boilerplate! ;-)


I don't understand Juergen's comment about meaningful names.
Info like ifAlias or ifName is 'just more data' and
covered by access control the same as other objects.


> All I am asking for that Netconf should not actively prohibit such a 
> solution.


What specific items in the murky solution space prohibit
which specific items in your problem space?  I don't see why
you couldn't come up with an access control model that works.




> Balazs

Andy

> 
> Juergen Schoenwaelder wrote:
>> On Thu, Apr 13, 2006 at 12:16:14PM -0700, Andy Bierman wrote:
>>  
>>> References in identifiers -- you mean like information
>>> carried in the instance portion of an OID?
>>>
>>> Not sure what you mean
>>
>> Operators seem to like to name things in meaningful ways and these
>> names frequently carry information which may be sensitive. If you want
>> to define views so that different people can look at a box, you have
>> to ensure that nothing leaks through which might be embedded in
>> operator assigned names (and thus can't be really handled by access
>> control rules unless you have embedded AI).
>>
>> /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 Fri Apr 14 11:44:28 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FUQTE-0005K3-VC
	for netconf-archive@lists.ietf.org; Fri, 14 Apr 2006 11:44:28 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FUQTE-0005ls-JT
	for netconf-archive@lists.ietf.org; Fri, 14 Apr 2006 11:44:28 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FUQQC-000MAg-Pu
	for netconf-data@psg.com; Fri, 14 Apr 2006 15:41: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.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 1FUQQC-000MAR-36
	for netconf@ops.ietf.org; Fri, 14 Apr 2006 15:41:20 +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 k3EFfI1Z009937;
	Fri, 14 Apr 2006 08:41:18 -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 k3EFfH546929;
	Fri, 14 Apr 2006 08:41:17 -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 k3EFkTYE035788;
	Fri, 14 Apr 2006 11:46:29 -0400 (EDT)
	(envelope-from phil@idle.juniper.net)
Message-Id: <200604141546.k3EFkTYE035788@idle.juniper.net>
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: architecture and security 
In-Reply-To: Your message of "Fri, 14 Apr 2006 11:14:40 +0200."
             <443F6800.7030501@ericsson.com> 
Date: Fri, 14 Apr 2006 11:46:29 -0400
From: Phil Shafer <phil@juniper.net>
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b

Balazs Lengyel writes:
>1) A router with multiple virtual routers.
>2) I have a big box: where user A is responsible for ...

One of the core concepts behind netconf was leveraging the existing
CLI concepts, infrastructure and implemenation to avoid being a
third management model (after the CLI and SNMP).  By avoiding this,
we hope to make netconf easier to implement, more powerful to use,
and more familiar to operators.

This was the motivation behind mirroring the existing configuration
models implemented by vendors (running, distinct-startup, candidate)
rather than rolling our own.  (It also helped us avoid the tendency
to invent new "must-have" features that no one ever heard of ;^)

So when I think of issues like classes of users and virtual routers,
the first question that comes to mind is how do existing routers
handle this?  Virtual routers are typically keyed off either incoming
interface or user login name.  The router knows which VR you are
accessing before you start entering commands.  This same solution
can be leveraged for netconf.  In the same way that a CLI user should
only see local log files or messages for their own VR, so a netconf
login should only have access to the notifications for the VR into
which the netconf session is attached.

Similar for classes of users.  If the CLI filters syslog files/messages
by user class, this same mechanism should be leveraged for netconf.  If
you couldn't see if as a user, you should see if as a netconf session.

So netconf should definitely not prevent you from doing the things
you want.  It should help you expose your device's abilities while
leveraging the existing infrastructure.

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 Thu Apr 20 13:40:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FWd8d-0007xG-LJ
	for netconf-archive@lists.ietf.org; Thu, 20 Apr 2006 13:40:19 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FWd8c-0004E4-Ap
	for netconf-archive@lists.ietf.org; Thu, 20 Apr 2006 13:40:19 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FWczH-0004w5-9H
	for netconf-data@psg.com; Thu, 20 Apr 2006 17:30: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 [205.178.146.54] (helo=ns-omrbm4.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FWczF-0004vr-Sf
	for netconf@ops.ietf.org; Thu, 20 Apr 2006 17:30:38 +0000
Received: from mail.networksolutionsemail.com (omr4.mgt.bos.netsol.com [10.49.2.114] (may be forged))
	by ns-omrbm4.netsolmail.com (8.12.10/8.12.10) with SMTP id k3KHL0Q3017682
	for <netconf@ops.ietf.org>; Thu, 20 Apr 2006 13:21:01 -0400
Received: (qmail 25107 invoked by uid 78); 20 Apr 2006 17:21:00 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.114 with SMTP; 20 Apr 2006 17:21:00 -0000
Message-ID: <4447C301.3000609@andybierman.com>
Date: Thu, 20 Apr 2006 10:21:05 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: minor <lock> ambiguity
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: bb8f917bb6b8da28fc948aeffb74aa17

Hi,

prot-12:sec. 7.5, para 2 says a lock request must fail
if "an existing session" hold the lock.

para 6, bullet 2 says a lock must not be granted
if "another NETCONF session" holds the locks.

Issue:  Does the agent need to check for the corner-case
where the manager is calling lock multiple times,
or is the agent strict and treat this as an error?

I remember we discussed this issue in the past, but I
don't remember making a decision:

Is it an error if a session call <lock> on a config
that it already locked?  This is probably a programming
error on the NMS, so IMO a lock-denied error should always be
returned if any attempt is made to lock an already locked config.

Therefore, para. 2 is correct and para. 6 is incorrect.

Can we agree on this interpretation so managers can expect
a consistent API?

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 Thu Apr 20 14:03:59 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FWdVX-0001uH-O2
	for netconf-archive@lists.ietf.org; Thu, 20 Apr 2006 14:03:59 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FWdVW-0005Ls-AB
	for netconf-archive@lists.ietf.org; Thu, 20 Apr 2006 14:03:59 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FWdPJ-00074Y-A3
	for netconf-data@psg.com; Thu, 20 Apr 2006 17:57:33 +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 1FWdPI-00074G-0d
	for netconf@ops.ietf.org; Thu, 20 Apr 2006 17:57: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 9BE973D;
	Thu, 20 Apr 2006 19:57:30 +0200 (CEST)
Date: Thu, 20 Apr 2006 19:57:21 +0200 (CEST)
Message-Id: <20060420.195721.55628255.mbj@tail-f.com>
To: ietf@andybierman.com
Cc: netconf@ops.ietf.org
Subject: Re: minor <lock> ambiguity
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4447C301.3000609@andybierman.com>
References: <4447C301.3000609@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: 8b30eb7682a596edff707698f4a80f7d

Andy Bierman <ietf@andybierman.com> wrote:
> Hi,
> 
> prot-12:sec. 7.5, para 2 says a lock request must fail
> if "an existing session" hold the lock.
> 
> para 6, bullet 2 says a lock must not be granted
> if "another NETCONF session" holds the locks.
> 
> Issue:  Does the agent need to check for the corner-case
> where the manager is calling lock multiple times,
> or is the agent strict and treat this as an error?
> 
> I remember we discussed this issue in the past, but I
> don't remember making a decision:
> 
> Is it an error if a session call <lock> on a config
> that it already locked?  This is probably a programming
> error on the NMS, so IMO a lock-denied error should always be
> returned if any attempt is made to lock an already locked config.
> 
> Therefore, para. 2 is correct and para. 6 is incorrect.
> 
> Can we agree on this interpretation so managers can expect
> a consistent API?

I think this is very reasonable.  (The description of lock-denied also
says "another entity".)

BTW, this is the way our agent behaves; i.e. it sends a lock-denied
error if the same session tries to grab a lock twice.


/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 Apr 20 14:29:36 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FWduK-0002e9-Mh
	for netconf-archive@lists.ietf.org; Thu, 20 Apr 2006 14:29:36 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FWduK-0006uL-DB
	for netconf-archive@lists.ietf.org; Thu, 20 Apr 2006 14:29:36 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FWdqG-0009Uz-Vl
	for netconf-data@psg.com; Thu, 20 Apr 2006 18:25: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.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 1FWdqG-0009Um-5o
	for netconf@ops.ietf.org; Thu, 20 Apr 2006 18:25:24 +0000
Received: from mail.networksolutionsemail.com (omr6.mgt.bos.netsol.com [10.49.2.116] (may be forged))
	by ns-omrbm6.netsolmail.com (8.12.10/8.12.10) with SMTP id k3KIPMkQ018993
	for <netconf@ops.ietf.org>; Thu, 20 Apr 2006 14:25:22 -0400
Received: (qmail 18454 invoked by uid 78); 20 Apr 2006 18:25:22 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.34.116 with SMTP; 20 Apr 2006 18:25:22 -0000
Message-ID: <4447D221.1020202@andybierman.com>
Date: Thu, 20 Apr 2006 11:25:37 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
CC: netconf@ops.ietf.org
Subject: Re: minor <lock> ambiguity
References: <4447C301.3000609@andybierman.com> <20060420.195721.55628255.mbj@tail-f.com>
In-Reply-To: <20060420.195721.55628255.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: 8b431ad66d60be2d47c7bfeb879db82c

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>> Hi,
>>
>> prot-12:sec. 7.5, para 2 says a lock request must fail
>> if "an existing session" hold the lock.
>>
>> para 6, bullet 2 says a lock must not be granted
>> if "another NETCONF session" holds the locks.
>>
>> Issue:  Does the agent need to check for the corner-case
>> where the manager is calling lock multiple times,
>> or is the agent strict and treat this as an error?
>>
>> I remember we discussed this issue in the past, but I
>> don't remember making a decision:
>>
>> Is it an error if a session call <lock> on a config
>> that it already locked?  This is probably a programming
>> error on the NMS, so IMO a lock-denied error should always be
>> returned if any attempt is made to lock an already locked config.
>>
>> Therefore, para. 2 is correct and para. 6 is incorrect.
>>
>> Can we agree on this interpretation so managers can expect
>> a consistent API?
> 
> I think this is very reasonable.  (The description of lock-denied also
> says "another entity".)
> 
> BTW, this is the way our agent behaves; i.e. it sends a lock-denied
> error if the same session tries to grab a lock twice.
> 

Mine too.

Also, an operation-failed error will be returned
if attempt to unlock a config that is not locked is made.
This is explicitly stated in sec. 7.6.
It would be inconsistent to treat this as an error,
but not the similar case for <lock>.

> 
> /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 Fri Apr 21 04:32:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FWr4O-0000hc-20
	for netconf-archive@lists.ietf.org; Fri, 21 Apr 2006 04:32:52 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FWr4K-0000Un-ND
	for netconf-archive@lists.ietf.org; Fri, 21 Apr 2006 04:32:52 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FWqy2-0000pa-8U
	for netconf-data@psg.com; Fri, 21 Apr 2006 08:26: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,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 1FWqy1-0000pN-B0
	for netconf@ops.ietf.org; Fri, 21 Apr 2006 08:26: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 k3L8PTap023368;
	Fri, 21 Apr 2006 03:25:30 -0500 (CDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <JHKTVZSG>; Fri, 21 Apr 2006 10:25:28 +0200
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509D5BE48@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Andy Bierman <ietf@andybierman.com>, Martin Bjorklund <mbj@tail-f.com>
Cc: netconf@ops.ietf.org
Subject: RE: minor <lock> ambiguity
Date: Fri, 21 Apr 2006 10:25:28 +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: d0bdc596f8dd1c226c458f0b4df27a88

I agree with this logic and support the statements
by Andy and Martin

Bert

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Andy Bierman
> Sent: Thursday, April 20, 2006 20:26
> To: Martin Bjorklund
> Cc: netconf@ops.ietf.org
> Subject: Re: minor <lock> ambiguity
> 
> 
> Martin Bjorklund wrote:
> > Andy Bierman <ietf@andybierman.com> wrote:
> >> Hi,
> >>
> >> prot-12:sec. 7.5, para 2 says a lock request must fail
> >> if "an existing session" hold the lock.
> >>
> >> para 6, bullet 2 says a lock must not be granted
> >> if "another NETCONF session" holds the locks.
> >>
> >> Issue:  Does the agent need to check for the corner-case
> >> where the manager is calling lock multiple times,
> >> or is the agent strict and treat this as an error?
> >>
> >> I remember we discussed this issue in the past, but I
> >> don't remember making a decision:
> >>
> >> Is it an error if a session call <lock> on a config
> >> that it already locked?  This is probably a programming
> >> error on the NMS, so IMO a lock-denied error should always be
> >> returned if any attempt is made to lock an already locked config.
> >>
> >> Therefore, para. 2 is correct and para. 6 is incorrect.
> >>
> >> Can we agree on this interpretation so managers can expect
> >> a consistent API?
> > 
> > I think this is very reasonable.  (The description of 
> lock-denied also
> > says "another entity".)
> > 
> > BTW, this is the way our agent behaves; i.e. it sends a lock-denied
> > error if the same session tries to grab a lock twice.
> > 
> 
> Mine too.
> 
> Also, an operation-failed error will be returned
> if attempt to unlock a config that is not locked is made.
> This is explicitly stated in sec. 7.6.
> It would be inconsistent to treat this as an error,
> but not the similar case for <lock>.
> 
> > 
> > /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/>
> 

--
to 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 Apr 21 13:49:33 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FWzl7-0002Y8-OS
	for netconf-archive@lists.ietf.org; Fri, 21 Apr 2006 13:49:33 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FWzl5-0006HP-Vp
	for netconf-archive@lists.ietf.org; Fri, 21 Apr 2006 13:49:33 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FWzfI-0009On-5t
	for netconf-data@psg.com; Fri, 21 Apr 2006 17:43: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.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME 
	autolearn=no 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 1FWzfG-0009OS-Dw
	for netconf@ops.ietf.org; Fri, 21 Apr 2006 17:43:30 +0000
Received: from localhost.localdomain (localhost [IPv6:::1])
	by diotima.switch.ch (8.13.5+Sun/8.13.5) with ESMTP id k3LHhPdU015557;
	Fri, 21 Apr 2006 19:43:27 +0200 (CEST)
From: simon@limmat.switch.ch
Message-ID: <17481.6588.962126.956382@localhost.localdomain>
Date: Fri, 21 Apr 2006 19:43:24 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="xSId1d02kZ"
Content-Transfer-Encoding: 7bit
To: netconf@ops.ietf.org
Subject: Minutes from NETCONF meeting at IETF65
X-Mailer: VM 7.19 under Emacs 22.0.50.1
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4


--xSId1d02kZ
Content-Type: text/plain; charset=us-ascii
Content-Description: message body and .signature
Content-Transfer-Encoding: 7bit

Here are the draft minutes from our meeting in Dallas last month.
If you have any corrections or additions, please send to the list.  
We have about two weeks for making corrections, but please review
them as soon as possible.  An HTML version can be found on 

http://www3.ietf.org/proceedings/06mar/minutes/netconf.html

Many thanks to Shane Kerr for taking notes!

Regards,
-- 
Simon.

--xSId1d02kZ
Content-Type: text/plain
Content-Disposition: inline;
	filename="minutes.txt"
Content-Transfer-Encoding: 7bit


              IETF65 Minutes: NETCONF (Network Configuration) WG

   20 March 2006, 0900-1045

   Chairs: Andy Bierman, Simon Leinen
   Security Advisor: Wes Hardaker
   Notes: Shane Kerr and Simon Leinen (Jabber)

IESG evaluation of the four initial WG documents

   The four initial WG documents ("NETCONF v1") are ready for approval by
   the IESG. One remaining issue concerns how many TCP port numbers
   should be assigned to the different protocol mappings (SSH, BEEP,
   SOAP/BEEP, SOAP/HTTP), and from which ranges.

  Port Assignments

   There was a discussion on whether all NETCONF protocol mappings
   require separate port number assignments, in particular the NETCONF
   over SOAP mappings.

   Wes Hardaker argues for separate port assignments, to allow the
   protocols to be filtered separately at firewalls. Andy and Sharon
   Chisholm agree that for the (mandatory) SSH mapping, a separate port
   is warranted, but wonder whether this use of known ports conforms to
   current practice with SOAP-based protocols.

   Wes points out that implementations will support configuration of a
   different port, such as the standard SOAP-over-HTTP port. David Black
   points to the usefulness of having separate ports in case of multiple
   SOAP engines on a device.

   No clear consensus in the room on whether all mappings (in particular
   the SOAP mappings) require assigments of separate ports. Wes notes
   that operators - rather than protocol developers - should say whether
   they want to be able to filter NETCONF separately.

  Well-known vs. registered ports

   The "well-known" port range below 1024 can only be used with special
   privileges on some systems, in particular those based on BSD. The
   "registered" port range between 1024 and 32767 can be used by any
   process. There had been vivid discussion on both the NETCONF and the
   general IETF mailing lists, with no clear consensus emerging.

   Andy started the discussion by arguing that if SSH uses a low port,
   then NETCONF, as a replacement for SSH, should use low ports as well.

   Margaret Wasserman notes that this means the process has to run with
   privileges at least for a short time to get the port. Simon counters
   that the protocol is used for configuration of device, so it needs
   some priviliges anyway. In addition, there are now least-privilege
   techniques for dealing with this.

   Wes notes that a privileged port makes it harder to spoof the NETCONF
   agent.

    Show of hands

   Andy asks for a show of hands - a large majority is in favor of
   requesting well-known ports.

Experimental NETCONF Registry

   Andy suggested that it could be useful to have a shared "sandbox"
   namespace for experimental extensions to NETCONF. This would be
   pursued without impacting the status of the current documents.

   In the discussion, Andy pointed out the advantages of such a registry,
   which could provide a vendor-neutral home for extension work that is
   not yet ready for standardization in the NETCONF WG, and a way for
   others to learn what extensions are being worked on elsewhere. Sharon
   is concerned about having to change namespaces twice when moving from
   a private namespace to the shared sandbox, and then to the official
   namespace when publishing the specification - this could mean three
   different versions in a shipped product. Andy points out that people
   don't have to use this. Ralph Weber would find such a registry useful
   for other working groups such as imss who consider building protocols
   based on NETCONF.

   Andy senses a lukewarm response to his suggestion, and proposes to ask
   for this registry as an individual. Bert Wijnen says that there is a
   template for such requests, and possibly a requirement for expert
   review.

Implementation Guide

   Andy suggests to attempt to publish an implementation guide as an
   informational RFC later, when enough operational experience has been
   gathered. Sharon likes the idea; in implementing NETCONF, we are
   starting to see a number of ambiguities, so some clarifications would
   be useful.

   A discussion ensued about whether it would be problematic to clarify
   things in an implementation guide rather than a standard. Dave
   Harrington is worried, if you have a document that clarifies a
   standard, what happens to that document if the underlying standard is
   revised? Eliot sees no problem unless normative text changes.

   Andy suggests that the implementation guide would tell things that you
   have to do that may not be in specifications. Eliot says that if
   normative text has to be interpreted, then it would be best to revise
   the standard. Wes notes that the chances of not having to revise the
   spec are slim. Andy thinks we need to actually see those problems that
   come up.

NETCONF Event Notifications

   Only very few people in the room admitted to having read the draft and
   being familiar with it. The chairs would have liked it to have been
   more. In an effort to get people to pay attention to this draft, we go
   through the document in detail.

  Notification Architecture

    Share session with "normal" NETCONF RPCs vs. dedicated session for
    notifications (syslog and CLI on single channel?)

   Do we need to mix notifications and replies on a single channel?

   Eliot Lear: The model is flexible depending on transport, and we
   should take advantage of that; for example in BEEP it would be natural
   to use a separate channel for notifications. He finds it important
   that the direction of the connection is suitable for the type of
   device being managed.

   Sharon Chisholm: Anything that precludes shared types? When you get
   more advanced, you start seeing advantage to doing this on same
   connection. For example, future extensions such as notification replay
   are more natural when the channel is shared. Why preclude this?

   Andy Bierman: If it adds complexity without being useful, then it is
   harmful.

   Sharon: We went with the current model rather than a dedicated
   notification channel. There are times related to insuring everything
   is going well where you would want to do that. Andy asks why one would
   ever not be able to open another channel? Sharon claims this is just
   trading complexity in one place for another.

   Dave Perkins points out that if somebody is logging config changes,
   you would see more events. Andy counters that in his code, they are
   logged just the same.

   Rob Enns finds that the only real benefit is having fewer connections.

   Andy is worried that having operations and notifications on the same
   channel would lead to head-of line blocking. Sanjay Singh asks wheter
   if notifications are done on a different channel, wouldn't they still
   be subject to head of line blocking in routers? Simon clarifies we're
   not talking about blocking in the network, but rather blocking by
   ongoing RPC (in particular large RPC responses) on the NETCONF
   channel.

   Sharon suggests we should do a Plan A vs. Plan B list, then sit down
   with a table and make a less subjective decision. Dave Harrington
   believes we need to consider exactly how we plan to use notifications.

    Use RPC model or separate model for notification?

      One-way RPC vs. Plain Notification

   Sharon explains there were 3 options: (1) remove the RPC layer for
   notifications; (2) use "one-way RPC" enclosure as done in the current
   draft; or (3) keep this additional layer but call it something else,
   such as "one-way message". Andy suggests we should figure out what
   needs to go in the message, and make layering match that.

      Subscription vs. Long-lived RPC Model

   Problem if use RPC model because you never get an end tag on your
   document.

  Notification Configurability

   Do we need the ability to modify a notification subscription? Andy
   suggests that alternatively, one could just start a fresh connection
   with the new subscription. Sharon is concerned about resource
   limitations on the NMS side. For a manager managing 20000 routers,
   these additional connections might be too costly to maintain.

   Andy asks whether multiple subscriptions need to be supported on a
   channel. Sharon finds this a useful low-cost feature, for example to
   allow short-lived subscriptions to additional events. Eliot isn't sure
   whether it makes a real difference where the multiplexing is done.

  Notification Messages

   Andy asks why an event should have multiple classes. Shouldn't
   everything fit in one class? Sharon disagrees. Simon likes Sharon's
   approach, but finds the "class" terminology confusing. Maybe a concept
   of "tags" like used in Flickr would be more useful.

  Event Classes

   How should events be modeled?

   Andy sees lots of things that we don't need: The heartbeat could be
   provided by the underlying transport (Saron counters that these
   application-level heartbeats have different semantics); metrics seem
   way out of scope, such messages would belong to IPFIX.

   Sharon claims we either need an exhaustive list of what NETCONF
   implementations will be doing, or have an extensible mechanism. Rob
   finds that it sounds like we're discussing data modeling, to which
   Sharon responds that the intention is to maintain clear separation
   between data model and protocol. Andy concedes that we hvae to bring
   in a certain amount of data modeling, but comments that we should not
   invent a new syslog.

Other Topics

   Sharon thinks that statistics about NETCONF itself would be useful.
   Dave Harrington recommends to use a data model that already exists
   [SMI] until the NETCONF group does define a data model. Andy sees a
   lot of use in having simple counters for debugging.

   Sharon reports that the work on data modeling has been de-prioritized,
   but encourages discussion on the netconfmodel mailing list or
   informally at this IETF meeting. Input on access control would be most
   welcome.

   Dan Romascanu concerning both data models and access control: if
   people have been experimenting in these areas, it would be best to
   make this work known.

   Andy about access control: He initially thought the SNMP approach with
   its fine-grained controls would be best, but it doesn't seem to be
   that useful. He's looking at a container model now. That may not be
   enough, but less granularity than SNMP should be sufficient.

Closing

   The chairs closed the meeting with a plea for participants to review
   the notification draft.

--xSId1d02kZ--

--
to 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 Apr 23 05:16:46 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FXagH-0003bo-FF
	for netconf-archive@lists.ietf.org; Sun, 23 Apr 2006 05:15:01 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FXaZQ-0001Ex-DT
	for netconf-archive@lists.ietf.org; Sun, 23 Apr 2006 05:08:01 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FXaQ4-0001xa-NL
	for netconf-data@psg.com; Sun, 23 Apr 2006 08:58:16 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,HTML_90_100,
	HTML_MESSAGE 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@switch.ch>)
	id 1FXaPz-0001x6-Lv
	for netconf@ops.ietf.org; Sun, 23 Apr 2006 08:58:13 +0000
Received: (from leinen@localhost)
	by diotima.switch.ch (8.13.5+Sun/8.13.5) id k3N8w9CO026257
	for netconf@ops.ietf.org; Sun, 23 Apr 2006 10:58:09 +0200 (CEST)
X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon@switch.ch using -f
X-From-Line: procmail  Wed Apr 19 05:08:50 2006
Received: from zinal.switch.ch ([130.59.108.20])
	by central.switch.ch with esmtp (Exim 3.20 #1)
	id 1FW33i-0003Mw-00
	for simon.leinen@switch.ch; Wed, 19 Apr 2006 05:08:50 +0200
Received: from localhost ([127.0.0.1] helo=zinal.switch.ch)
	by zinal.switch.ch with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.54)
	id 1FW33i-00077b-HQ
	for simon.leinen@switch.ch; Wed, 19 Apr 2006 05:08:50 +0200
Received: from localhost ([::1] helo=zinal.switch.ch)
	by zinal.switch.ch with esmtp (Exim 4.54)
	id 1FW33V-00077Q-Cm
	for simon.leinen@switch.ch; Wed, 19 Apr 2006 05:08:37 +0200
Received: from [147.28.0.62] (helo=psg.com)
	by zinal.switch.ch with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.54)
	id 1FW33U-00077N-Nx
	for simon@limmat.switch.ch; Wed, 19 Apr 2006 05:08:37 +0200
Received: from [61.144.161.54] (helo=huawei.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <liyan_77@huawei.com>)
	id 1FW33H-000F96-30
	for owner-netconf@ops.ietf.org; Wed, 19 Apr 2006 03:08:34 +0000
Received: from huawei.com (szxga02-in [172.24.2.6])
 by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built
 Mar
 3 2004)) with ESMTP id <0IXY006TK99BQ0@szxga02-in.huawei.com> for
 owner-netconf@ops.ietf.org; Wed, 19 Apr 2006 11:20:00 +0800 (CST)
Received: from huawei.com ([172.24.1.3])
 by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built
 Mar
 3 2004)) with ESMTP id <0IXY00C7L99BNI@szxga02-in.huawei.com> for
 owner-netconf@ops.ietf.org; Wed, 19 Apr 2006 11:19:59 +0800 (CST)
Received: from l48181 ([10.110.114.146])
 by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built
 Mar
 3 2004)) with ESMTPA id <0IXY00HFG9EZGS@szxml01-in.huawei.com> for
 owner-netconf@ops.ietf.org; Wed, 19 Apr 2006 11:23:32 +0800 (CST)
Date: Wed, 19 Apr 2006 11:05:40 +0800
From: Li Yan <liyan_77@huawei.com>
Subject: A question about <edit-config> operation
To: owner-netconf@ops.ietf.org
Message-id: <000001c6635e$27277210$92726e0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: multipart/alternative;
 boundary="Boundary_(ID_t1D93VDM5sdNA2I9tHxOQw)"
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-SWITCH-SIGNATURE: bb5538d077d7ad658c8f3d76e56c4dda
X-SWITCH-MailScanner: Found to be clean
X-SWITCH-MailScanner-SpamCheck: spam, SpamAssassin (score=0.024, required 0,
	BAYES_50 0.00, HTML_90_100 0.02, HTML_MESSAGE 0.00)
X-SWITCH-SCANNER: scanned
Lines: 358
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d

This is a multi-part message in MIME format.

--Boundary_(ID_t1D93VDM5sdNA2I9tHxOQw)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi,

I think the changed object is ambiguous in <edit-config> operation. For
example:

<rpc message-id="101"

      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <edit-config>

    <target>

      <running/>

    </target>

    <config>

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

        <interface>

          <name>Ethernet0/0</name>

          <mtu>1500</mtu>

        </interface>

      </top>

    </config>

  </edit-config>

</rpc>

We usually think it set the MTU to 1500 on an interface named "Ethernet0/0",
but why don't think it set the name to "Ethernet0/0" on interfaces whose MTU
equal to 1500?

If I want to set the MTU to 1500 on the interfaces whose MTU equal to 1300,
How shall I depict the <edit-config> operation using XML?

 


--Boundary_(ID_t1D93VDM5sdNA2I9tHxOQw)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">


<meta name=Generator content="Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimHei;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:KaiTi_GB2312;
	panose-1:2 1 6 9 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:KaiTi_GB2312;
	panose-1:2 1 6 9 3 1 1 1 1 1;}
@font-face
	{font-family:SimHei;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	text-indent:21.0pt;
	line-height:150%;
	text-autospace:none;
	font-size:10.5pt;
	font-family:"Times New Roman";}
h1
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:21.6pt;
	text-align:justify;
	text-justify:inter-ideograph;
	text-indent:-21.6pt;
	page-break-after:avoid;
	font-size:16.0pt;
	font-family:Arial;}
h2
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:28.8pt;
	text-align:justify;
	text-justify:inter-ideograph;
	text-indent:-28.8pt;
	page-break-after:avoid;
	font-size:12.0pt;
	font-family:Arial;
	font-weight:normal;}
h3
	{margin-top:13.0pt;
	margin-right:0cm;
	margin-bottom:13.0pt;
	margin-left:36.0pt;
	text-align:justify;
	text-justify:inter-ideograph;
	text-indent:-36.0pt;
	line-height:173%;
	page-break-after:avoid;
	font-size:12.0pt;
	font-family:"Times New Roman";
	font-weight:normal;}
p.MsoHeader, li.MsoHeader, div.MsoHeader
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	layout-grid-mode:char;
	font-size:9.0pt;
	font-family:Arial;}
p.MsoFooter, li.MsoFooter, div.MsoFooter
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:9.0pt;
	font-family:Arial;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.a, li.a, div.a
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:54.45pt;
	margin-bottom:.0001pt;
	text-align:center;
	text-indent:-18.45pt;
	font-size:9.0pt;
	font-family:Arial;}
p.a0, li.a0, div.a0
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Arial;}
p.a1, li.a1, div.a1
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:center;
	font-size:10.5pt;
	font-family:Arial;
	font-weight:bold;}
p.a2, li.a2, div.a2
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:12.0pt;
	margin-left:54.45pt;
	text-align:center;
	text-indent:-18.45pt;
	font-size:9.0pt;
	font-family:Arial;}
p.a3, li.a3, div.a3
	{margin-top:4.0pt;
	margin-right:0cm;
	margin-bottom:4.0pt;
	margin-left:0cm;
	text-align:center;
	line-height:150%;
	page-break-after:avoid;
	text-autospace:none;
	font-size:10.5pt;
	font-family:"Times New Roman";}
p.a4, li.a4, div.a4
	{margin-top:15.0pt;
	margin-right:0cm;
	margin-bottom:15.0pt;
	margin-left:0cm;
	text-align:center;
	line-height:150%;
	text-autospace:none;
	font-size:18.0pt;
	font-family:Arial;}
p.a5, li.a5, div.a5
	{margin:0cm;
	margin-bottom:.0001pt;
	line-height:150%;
	text-autospace:none;
	font-size:10.5pt;
	font-family:"Times New Roman";}
p.a6, li.a6, div.a6
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	line-height:150%;
	text-autospace:none;
	border:none;
	padding:0cm;
	font-size:9.0pt;
	font-family:Arial;}
p.a7, li.a7, div.a7
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	text-indent:18.0pt;
	line-height:150%;
	text-autospace:none;
	border:none;
	padding:0cm;
	font-size:9.0pt;
	font-family:Arial;}
p.a8, li.a8, div.a8
	{margin:0cm;
	margin-bottom:.0001pt;
	text-indent:21.0pt;
	line-height:150%;
	text-autospace:none;
	font-size:10.5pt;
	font-family:Arial;
	color:blue;
	font-style:italic;}
span.EmailStyle30
	{font-family:Arial;
	color:windowtext;}
 /* Page Definitions */
 @page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	layout-grid:15.6pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>

</head>

<body lang=ZH-CN link=blue vlink=purple style='text-justify-trim:punctuation'>

<div class=Section1 style='layout-grid:15.6pt'>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt;line-height:150%'><span style='line-height:150%'>Hi,</span></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt;line-height:150%'><span style='line-height:150%'>I
think the changed object is ambiguous in &lt;edit-config&gt; operation. For example:</span></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt;line-height:150%'><span style='line-height:150%'>&lt;rpc
message-id=&quot;101&quot;</span></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt;line-height:150%'><span style='line-height:150%'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
xmlns=&quot;urn:ietf:params:xml:ns:netconf:base:1.0&quot;&gt;</span></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt;line-height:150%'><span style='line-height:150%'>&nbsp;
&lt;edit-config&gt;</span></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt;line-height:150%'><span style='line-height:150%'>&nbsp;&nbsp;&nbsp;
&lt;target&gt;</span></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt;line-height:150%'><span style='line-height:150%'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;running/&gt;</span></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt;line-height:150%'><span style='line-height:150%'>&nbsp;&nbsp;&nbsp;
&lt;/target&gt;</span></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt;line-height:150%'><span style='line-height:150%'>&nbsp;&nbsp;&nbsp;
&lt;config&gt;</span></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt;line-height:150%'><span style='line-height:150%'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;top xmlns=&quot;http://example.com/schema/1.2/config&quot;&gt;</span></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt;line-height:150%'><span style='line-height:150%'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;interface&gt;</span></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt;line-height:150%'><span style='line-height:150%'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&lt;name&gt;Ethernet0/0&lt;/name&gt;</span></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt;line-height:150%'><span style='line-height:150%'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;mtu&gt;1500&lt;/mtu&gt;</span></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt;line-height:150%'><span style='line-height:150%'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;/interface&gt;</span></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt;line-height:150%'><span style='line-height:150%'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;/top&gt;</span></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt;line-height:150%'><span style='line-height:150%'>&nbsp;&nbsp;&nbsp;
&lt;/config&gt;</span></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt;line-height:150%'><span style='line-height:150%'>&nbsp;
&lt;/edit-config&gt;</span></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt;line-height:150%'><span style='line-height:150%'>&lt;/rpc&gt;</span></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt;line-height:150%'><span style='line-height:150%'>We usually
think it set the MTU to 1500 on an interface named &quot;Ethernet0/0&quot;, but
why don&#8217;t think it set the name to &#8220;Ethernet0/0&#8221; on interfaces
whose MTU equal to 1500?</span></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.5pt;line-height:150%'><span style='line-height:150%'>If I want
to set the MTU to 1500 on the interfaces whose MTU equal to 1300, How shall I depict
the &lt;edit-config&gt; operation using XML?</span></span></font></p>

<p class=MsoNormal style='text-indent:18.0pt'><font size=1 face=Arial><span
lang=EN-US style='font-size:9.0pt;line-height:150%;font-family:Arial'>&nbsp;</span></font></p>

</div>

</body>

</html>

--Boundary_(ID_t1D93VDM5sdNA2I9tHxOQw)--


--
to 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 Apr 23 10:51:45 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FXfw9-0008Ee-EK
	for netconf-archive@lists.ietf.org; Sun, 23 Apr 2006 10:51:45 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FXfw8-0000PL-1G
	for netconf-archive@lists.ietf.org; Sun, 23 Apr 2006 10:51:45 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FXfqS-0001gG-Is
	for netconf-data@psg.com; Sun, 23 Apr 2006 14:45: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.56] (helo=ns-omrbm6.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FXfqR-0001g1-Ch
	for netconf@ops.ietf.org; Sun, 23 Apr 2006 14:45:51 +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 k3NEjoev016140
	for <netconf@ops.ietf.org>; Sun, 23 Apr 2006 10:45:50 -0400
Received: (qmail 16041 invoked by uid 78); 23 Apr 2006 14:45:50 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.69 with SMTP; 23 Apr 2006 14:45:50 -0000
Message-ID: <444B930E.2050107@andybierman.com>
Date: Sun, 23 Apr 2006 07:45:34 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Li Yan <liyan_77@huawei.com>
CC: netconf@ops.ietf.org
Subject: Re: A question about <edit-config> operation
References: <000001c6635e$27277210$92726e0a@china.huawei.com>
In-Reply-To: <000001c6635e$27277210$92726e0a@china.huawei.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248

Li Yan wrote:
> Hi,
> 
> I think the changed object is ambiguous in <edit-config> operation. For 
> example:
> 
> <rpc message-id="101"
> 
>       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> 
>   <edit-config>
> 
>     <target>
> 
>       <running/>
> 
>     </target>
> 
>     <config>
> 
>       <top xmlns="http://example.com/schema/1.2/config">
> 
>         <interface>
> 
>           <name>Ethernet0/0</name>
> 
>           <mtu>1500</mtu>
> 
>         </interface>
> 
>       </top>
> 
>     </config>
> 
>   </edit-config>
> 
> </rpc>
> 
> We usually think it set the MTU to 1500 on an interface named 
> "Ethernet0/0", but why don’t think it set the name to “Ethernet0/0” on 
> interfaces whose MTU equal to 1500?


Because the schema that defines the structure and semantics of
the data model (not shown here) says the key for instance uniqueness
is the <name> element, not the <mtu> element.

A comment will be added to the prot-13 draft to make this
seemingly obvious detail more clear.


> 
> If I want to set the MTU to 1500 on the interfaces whose MTU equal to 
> 1300, How shall I depict the <edit-config> operation using XML?


You can't do this with NETCONF edit-config.
Maybe you can with XSLT, but NE configuration
involves more than manipulating an XML document.

NETCONF does not have a set-wildcard function.  You need
to specify each instance you are changing (using
the key defined for that data model), along with
the new <mtu> value -- or define an RPC or data model
that has "change all <mtu> elements from X to Y" semantics.



> 
>  
> 


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 Apr 23 12:31:27 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FXhUd-0001RG-3H
	for netconf-archive@lists.ietf.org; Sun, 23 Apr 2006 12:31:27 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FXhUb-0006Eq-P2
	for netconf-archive@lists.ietf.org; Sun, 23 Apr 2006 12:31:27 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FXhQb-0006zR-Nn
	for netconf-data@psg.com; Sun, 23 Apr 2006 16:27: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 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 1FXhQa-0006zC-H8
	for netconf@ops.ietf.org; Sun, 23 Apr 2006 16:27:17 +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 k3NGO3BO011489
	for <netconf@ops.ietf.org>; Sun, 23 Apr 2006 12:24:05 -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: RE: A question about <edit-config> operation
Date: Sun, 23 Apr 2006 19:27:13 +0300
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A647A16@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: A question about <edit-config> operation
Thread-Index: AcZm5NvBwEGWCGDeTDC5BRu4uKK6bwADZX/Q
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Andy Bierman" <ietf@andybierman.com>, "Li Yan" <liyan_77@huawei.com>
Cc: <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: 3e15cc4fdc61d7bce84032741d11c8e5



=20
=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> >=20
> > We usually think it set the MTU to 1500 on an interface named=20
> > "Ethernet0/0", but why don't think it set the name to=20
> "Ethernet0/0" on=20
> > interfaces whose MTU equal to 1500?
>=20
>=20
> Because the schema that defines the structure and semantics=20
> of the data model (not shown here) says the key for instance=20
> uniqueness is the <name> element, not the <mtu> element.
>=20
> A comment will be added to the prot-13 draft to make this=20
> seemingly obvious detail more clear.
>=20

I am not sure that there will be a prot-13 draft. draft-...prot-12 was
approved by the IESG and submitted to the RFC Editor. You are probably
referring to the following change which will show up in the RFC version:


Page 39, bottom:

OLD:

   Example:

       Set the MTU to 1500 on an interface named "Ethernet0/0" in the
       running configuration:

NEW:

   Example:

       The <edit-config> examples in this section utilize a simple
       data model, in which multiple instances of the 'interface'
       element may be present, and an instance is distinguished
       by the 'name' element within each 'interface' element.

       Set the MTU to 1500 on an interface named "Ethernet0/0" in the
       running configuration:

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 Wed Apr 26 12:20:00 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FYmkC-0002jo-MF
	for netconf-archive@lists.ietf.org; Wed, 26 Apr 2006 12:20:00 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FYmkC-0005Yw-9Q
	for netconf-archive@lists.ietf.org; Wed, 26 Apr 2006 12:20:00 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FYmdw-000AHJ-Kq
	for netconf-data@psg.com; Wed, 26 Apr 2006 16:13: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=BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [192.160.73.61] (helo=ondar.cablelabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <e.cardona@CableLabs.com>)
	id 1FYmdv-000AGu-Jq
	for netconf@ops.ietf.org; Wed, 26 Apr 2006 16:13:31 +0000
Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20])
	by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k3QGDKnS017105;
	Wed, 26 Apr 2006 10:13:20 -0600 (MDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Notification Requirements Consensus Points
Date: Wed, 26 Apr 2006 10:13:19 -0600
Message-ID: <5259D0D7419C6149B347837A2E64F46F01856930@srvxchg.cablelabs.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notification Requirements Consensus Points
Thread-Index: AcZekAUz1KcbwSaqT3Kh+HrPSJCFBAKtY1mw
From: "Eduardo Cardona" <e.cardona@CableLabs.com>
To: "Andy Bierman" <ietf@andybierman.com>,
        "Netconf (E-mail)" <netconf@ops.ietf.org>
X-Approved: ondar
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a

Hi,=20
I am not a WG contributor, but I follow with interest the discussions.

"There does not seem to be consensus on these points:
...
- RPC operations and notifications should be mixed on the same session"


I can see pros and cons for the implementation as already stated by the
WG. One thing is what the architecture should be, one is what works,
scale, is deployed and sold. Where the line is set?=20

My question is more Where IETF is moving on session/applications from
the transport protocol perspective? And plug the applications protocols
right there.

For example :=20
BEEP offers channels;  SCTP ( not a protocol required for Net-Conf)
offers streams within an association (session).=20
What about Netconf for wireless/Satellite/slow/far networks where mixed
RPCs and large RPCs maybe a problem?=20

A compromised solution could be to define for BEEP the notification
channel and the configuration channel. SSH/SOAP (TCP) a negotiable
feature:
- Require for the Managed element to support both (in session and
different session notifications)=20
- Require for the Manager ( the TCP session resources constrained
device) to support either one or the other, or both.=20

In this way the specialization is performed at the manager based on the
needs, and not at the network element


Although my preference is separate sessions (e.g BEEP channels, TCP
sessions) -> SCTP streams !  - solve the architecture paradigm (is there
any?)=20

Thanks

Eduardo

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]=20
Sent: Wednesday, April 12, 2006 6:16 PM
To: Netconf (E-mail)
Subject: Notification Requirements Consensus Points

Hi,

It is difficult to measure WG consensus.
It seems like no matter what the issue is,
there are about equal numbers of opinions on either side.

There seems to be consensus on these points:
 - Top level message is <notification> (rpc-one-way is out)
 - Separation of header and content-independent data is needed
 - Both the manager subscription model and traditional agent-configured
   notification generator model should be supported
 - The header should include some type of classification
   (e.g., event-class).=20
 - The ability to filter (i.e., drop) notifications at the source
   based on event class and notification data content is needed.=20
   Access control is impacted by this feature.
 - Named profiles (if kept) need to be fully specified in a
   standard read-create data model.
 - There is no limit on the length of the notification data
   (same as for RPC data)

There does not seem to be consensus on these points:
 - The specific role of notifications in the netconf protocol
   or whether a specific role is even needed
 - The use of a read-only instead of a read-create data model
   for notification generation parameters
 - The use of specialized RPCs instead of a standard data model
   to configure notification generation parameters
 - The need for named profiles (issue is irrelevant if read-create
   data model approach is used)
 - Multiple subscriptions per session are needed
 - RPC operations and notifications should be mixed on the same session
 - The specific list of event classes, or
   whether this document or IANA maintains the list, or
   whether we even need a list at all (i.e., just a string match).
 - The need for a modify-subscription feature
   (Note that this is implicitly supported by edit-config if a
   read-create data model is used)
 - The use of an endless-RPC model (which is only relevant if
   the WG decides mixed-mode sessions are not required)
 - The specific standard notifications (if any) that an agent
   must support



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 Apr 26 12:41:28 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FYn4y-00051F-T6
	for netconf-archive@lists.ietf.org; Wed, 26 Apr 2006 12:41:28 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FYn4w-0006sJ-CA
	for netconf-archive@lists.ietf.org; Wed, 26 Apr 2006 12:41:28 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FYn0v-000C3q-5F
	for netconf-data@psg.com; Wed, 26 Apr 2006 16:37: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.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FYn0t-000C3b-Oc
	for netconf@ops.ietf.org; Wed, 26 Apr 2006 16:37:15 +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 k3QGbB1M002149
	for <netconf@ops.ietf.org>; Wed, 26 Apr 2006 12:37:14 -0400
Received: (qmail 28174 invoked by uid 78); 26 Apr 2006 16:35:46 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 26 Apr 2006 16:35:46 -0000
Message-ID: <444FA15C.5070902@andybierman.com>
Date: Wed, 26 Apr 2006 09:35:40 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Eduardo Cardona <e.cardona@CableLabs.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Requirements Consensus Points
References: <5259D0D7419C6149B347837A2E64F46F01856930@srvxchg.cablelabs.com>
In-Reply-To: <5259D0D7419C6149B347837A2E64F46F01856930@srvxchg.cablelabs.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: d2b46e3b2dfbff2088e0b72a54104985

Eduardo Cardona wrote:
> Hi, 
> I am not a WG contributor, but I follow with interest the discussions.
> 
> "There does not seem to be consensus on these points:
> ...
> - RPC operations and notifications should be mixed on the same session"
> 
> 
> I can see pros and cons for the implementation as already stated by the
> WG. One thing is what the architecture should be, one is what works,
> scale, is deployed and sold. Where the line is set? 
> 
> My question is more Where IETF is moving on session/applications from
> the transport protocol perspective? And plug the applications protocols
> right there.
> 
> For example : 
> BEEP offers channels;  SCTP ( not a protocol required for Net-Conf)
> offers streams within an association (session). 
> What about Netconf for wireless/Satellite/slow/far networks where mixed
> RPCs and large RPCs maybe a problem? 
> 
> A compromised solution could be to define for BEEP the notification
> channel and the configuration channel. SSH/SOAP (TCP) a negotiable
> feature:
> - Require for the Managed element to support both (in session and
> different session notifications) 
> - Require for the Manager ( the TCP session resources constrained
> device) to support either one or the other, or both. 
> 
> In this way the specialization is performed at the manager based on the
> needs, and not at the network element

We already have plenty of options (i.e., capabilities).
None of them are specific to any transport layer -- by design.
The WG already rejected the idea of different notifications
(and control channels, etc.) for each transport.

The netconf architecture only works if each layer hides the
layer underneath it.  Is this feature important enough
to incur the complexity it would cost to support it
on all transports, mandatory in all agent implementations?

IMO, we are close to deciding that mixed-mode (what I call
sharing 1 NETCONF session for notifications and operations)
is not important to enough people to support.

Your proposal sounds like you don't want to mix notifications
and operations together, but if other people to, then here is
a way to do that.  Is that correct?

I would like to see emails that clearly state
"we have this requirement in our product/service/network"
for specific features", or "we do not plan to use feature X".

The only example of mixed mode that has been given is
the ability for current CLI implementations to be configured to
send spurious system console messages to the terminal.
I don't see how that really applies to a programmatic
interface like NETCONF.  The messages can be much larger,
and the interactions more complicated in NETCONF.


> 
> 
> Although my preference is separate sessions (e.g BEEP channels, TCP
> sessions) -> SCTP streams !  - solve the architecture paradigm (is there
> any?) 
> 
> Thanks
> 
> Eduardo

Andy

> 
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com] 
> Sent: Wednesday, April 12, 2006 6:16 PM
> To: Netconf (E-mail)
> Subject: Notification Requirements Consensus Points
> 
> Hi,
> 
> It is difficult to measure WG consensus.
> It seems like no matter what the issue is,
> there are about equal numbers of opinions on either side.
> 
> There seems to be consensus on these points:
>  - Top level message is <notification> (rpc-one-way is out)
>  - Separation of header and content-independent data is needed
>  - Both the manager subscription model and traditional agent-configured
>    notification generator model should be supported
>  - The header should include some type of classification
>    (e.g., event-class). 
>  - The ability to filter (i.e., drop) notifications at the source
>    based on event class and notification data content is needed. 
>    Access control is impacted by this feature.
>  - Named profiles (if kept) need to be fully specified in a
>    standard read-create data model.
>  - There is no limit on the length of the notification data
>    (same as for RPC data)
> 
> There does not seem to be consensus on these points:
>  - The specific role of notifications in the netconf protocol
>    or whether a specific role is even needed
>  - The use of a read-only instead of a read-create data model
>    for notification generation parameters
>  - The use of specialized RPCs instead of a standard data model
>    to configure notification generation parameters
>  - The need for named profiles (issue is irrelevant if read-create
>    data model approach is used)
>  - Multiple subscriptions per session are needed
>  - RPC operations and notifications should be mixed on the same session
>  - The specific list of event classes, or
>    whether this document or IANA maintains the list, or
>    whether we even need a list at all (i.e., just a string match).
>  - The need for a modify-subscription feature
>    (Note that this is implicitly supported by edit-config if a
>    read-create data model is used)
>  - The use of an endless-RPC model (which is only relevant if
>    the WG decides mixed-mode sessions are not required)
>  - The specific standard notifications (if any) that an agent
>    must support
> 
> 
> 
> 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 Apr 26 20:17:33 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FYuCL-0003cF-7X
	for netconf-archive@lists.ietf.org; Wed, 26 Apr 2006 20:17:33 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FYuCI-00010u-Tt
	for netconf-archive@lists.ietf.org; Wed, 26 Apr 2006 20:17:33 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FYu7D-000Hij-MI
	for netconf-data@psg.com; Thu, 27 Apr 2006 00:12:15 +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 1FYu7C-000HiV-Gl
	for netconf@ops.ietf.org; Thu, 27 Apr 2006 00:12:15 +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 k3R0C9DD010268
	for <netconf@ops.ietf.org>; Wed, 26 Apr 2006 20:12:13 -0400
Received: (qmail 23110 invoked by uid 78); 27 Apr 2006 00:12:09 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.67 with SMTP; 27 Apr 2006 00:12:09 -0000
Message-ID: <44500C53.7010307@andybierman.com>
Date: Wed, 26 Apr 2006 17:12:03 -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: Martin Bjorklund <mbj@tail-f.com>, netconf@ops.ietf.org,
        Dan Romascanu <dromasca@avaya.com>
Subject: Re: minor <lock> ambiguity
References: <7D5D48D2CAA3D84C813F5B154F43B15509D5BE48@nl0006exch001u.nl.lucent.com>
In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15509D5BE48@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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f

Wijnen, Bert (Bert) wrote:
> I agree with this logic and support the statements
> by Andy and Martin

So here is the RFC Editor note:

draft-ietf-netconf-prot-12.txt, page 46, para 6:

OLD:

     A lock MUST not be granted if any of the following conditions are
     true:

       *  a lock is already held by another NETCONF session or another
                                    ^^^^^^^
          entity

NEW:

     A lock MUST not be granted if any of the following conditions are
     true:

       *  a lock is already held by any NETCONF session or another
          entity



> 
> Bert

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 Apr 27 08:56:50 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FZ638-0000y7-I6
	for netconf-archive@lists.ietf.org; Thu, 27 Apr 2006 08:56:50 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FZ636-000302-10
	for netconf-archive@lists.ietf.org; Thu, 27 Apr 2006 08:56:50 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FZ5vQ-000P5y-62
	for netconf-data@psg.com; Thu, 27 Apr 2006 12:48: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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [192.160.73.61] (helo=ondar.cablelabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <e.cardona@CableLabs.com>)
	id 1FZ5vO-000P5j-Ve
	for netconf@ops.ietf.org; Thu, 27 Apr 2006 12:48:51 +0000
Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20])
	by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k3RCmlPv026575;
	Thu, 27 Apr 2006 06:48:48 -0600 (MDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Notification Requirements Consensus Points
Date: Thu, 27 Apr 2006 06:48:47 -0600
Message-ID: <5259D0D7419C6149B347837A2E64F46F01856A59@srvxchg.cablelabs.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notification Requirements Consensus Points
Thread-Index: AcZpT7BFdPEbS4dMRQKFcgfkWmctgwAm63xg
From: "Eduardo Cardona" <e.cardona@CableLabs.com>
To: "Andy Bierman" <ietf@andybierman.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
X-Approved: ondar
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c


See inline


-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]=20
Sent: Wednesday, April 26, 2006 10:36 AM
To: Eduardo Cardona
Cc: Netconf (E-mail)
Subject: Re: Notification Requirements Consensus Points

Eduardo Cardona wrote:
> Hi,=20
> I am not a WG contributor, but I follow with interest the discussions.
>=20
> "There does not seem to be consensus on these points:
> ...
> - RPC operations and notifications should be mixed on the same
session"
>=20
>=20
> I can see pros and cons for the implementation as already stated by
the
> WG. One thing is what the architecture should be, one is what works,
> scale, is deployed and sold. Where the line is set?=20
>=20
> My question is more Where IETF is moving on session/applications from
> the transport protocol perspective? And plug the applications
protocols
> right there.
>=20
> For example :=20
> BEEP offers channels;  SCTP ( not a protocol required for Net-Conf)
> offers streams within an association (session).=20
> What about Netconf for wireless/Satellite/slow/far networks where
mixed
> RPCs and large RPCs maybe a problem?=20
>=20
> A compromised solution could be to define for BEEP the notification
> channel and the configuration channel. SSH/SOAP (TCP) a negotiable
> feature:
> - Require for the Managed element to support both (in session and
> different session notifications)=20
> - Require for the Manager ( the TCP session resources constrained
> device) to support either one or the other, or both.=20
>=20
> In this way the specialization is performed at the manager based on
the
> needs, and not at the network element

We already have plenty of options (i.e., capabilities).
None of them are specific to any transport layer -- by design.
The WG already rejected the idea of different notifications
(and control channels, etc.) for each transport.

The netconf architecture only works if each layer hides the
layer underneath it.  Is this feature important enough
to incur the complexity it would cost to support it
on all transports, mandatory in all agent implementations?


<edo>
As a closure note ( this item is tangential to the discussion) this
layer separation I believe is a TCP paradigm. My point is that the rich
features of the transport models are to be used by the applications for
performance and robustness. This applies to management protocols as well
- and a clean solution I believe for the "inline" notifications
(mix-mode) e.g. BEEP channels -=20

However, clean is never free.

Otherwise, IMO mix-mode has architecture contradictions beyond TCP.
I don't necessarily share that netconf need to be connection-oriented
transport agnostic beyond TCP

- I guess is more a matter of IETF direction for next generation
applications.=20
</edo>

IMO, we are close to deciding that mixed-mode (what I call
sharing 1 NETCONF session for notifications and operations)
is not important to enough people to support.

Your proposal sounds like you don't want to mix notifications
and operations together, but if other people to, then here is
a way to do that.  Is that correct?

<edo>
Yes that's the idea,=20
If the "inline" notifications (mix-mode) is supported, I think is easy
for the managed device to dump the notifications in the same session but
at discretion of the manager willingness to handle that burden, and the
manager decides the model during the notification subscription process.

As I said, I prefer the separation of channels for Notifications and
Configuration.=20

But I am sensitive as well of vertical solutions as well and vendor
differentiation options. =20

However, the "inline" processing of messages is what I see a
perpetuation of old application development models like CLI expect
command processing - pointing to the CLI use case you mentioned below- ,
rather than OO event driven models. That's where IMO the mix-mode
feature hurts the architecture of the protocol for the next 10-20 years
of its life time. The transport model capability I mentioned, provides
mechanisms to evolve the protocol itself to new applications models.
</edo>

I would like to see emails that clearly state
"we have this requirement in our product/service/network"
for specific features", or "we do not plan to use feature X".

The only example of mixed mode that has been given is
the ability for current CLI implementations to be configured to
send spurious system console messages to the terminal.
I don't see how that really applies to a programmatic
interface like NETCONF.  The messages can be much larger,
and the interactions more complicated in NETCONF.

<edo>
Agree
</edo>

>=20
>=20
> Although my preference is separate sessions (e.g BEEP channels, TCP
> sessions) -> SCTP streams !  - solve the architecture paradigm (is
there
> any?)=20
>=20
> Thanks
>=20
> Eduardo

Andy

>=20
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com]=20
> Sent: Wednesday, April 12, 2006 6:16 PM
> To: Netconf (E-mail)
> Subject: Notification Requirements Consensus Points
>=20
> Hi,
>=20
> It is difficult to measure WG consensus.
> It seems like no matter what the issue is,
> there are about equal numbers of opinions on either side.
>=20
> There seems to be consensus on these points:
>  - Top level message is <notification> (rpc-one-way is out)
>  - Separation of header and content-independent data is needed
>  - Both the manager subscription model and traditional
agent-configured
>    notification generator model should be supported
>  - The header should include some type of classification
>    (e.g., event-class).=20
>  - The ability to filter (i.e., drop) notifications at the source
>    based on event class and notification data content is needed.=20
>    Access control is impacted by this feature.
>  - Named profiles (if kept) need to be fully specified in a
>    standard read-create data model.
>  - There is no limit on the length of the notification data
>    (same as for RPC data)
>=20
> There does not seem to be consensus on these points:
>  - The specific role of notifications in the netconf protocol
>    or whether a specific role is even needed
>  - The use of a read-only instead of a read-create data model
>    for notification generation parameters
>  - The use of specialized RPCs instead of a standard data model
>    to configure notification generation parameters
>  - The need for named profiles (issue is irrelevant if read-create
>    data model approach is used)
>  - Multiple subscriptions per session are needed
>  - RPC operations and notifications should be mixed on the same
session
>  - The specific list of event classes, or
>    whether this document or IANA maintains the list, or
>    whether we even need a list at all (i.e., just a string match).
>  - The need for a modify-subscription feature
>    (Note that this is implicitly supported by edit-config if a
>    read-create data model is used)
>  - The use of an endless-RPC model (which is only relevant if
>    the WG decides mixed-mode sessions are not required)
>  - The specific standard notifications (if any) that an agent
>    must support
>=20
>=20
>=20
> Andy
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>=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/>



From owner-netconf@ops.ietf.org Thu Apr 27 10:41:27 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FZ7gN-0006Sp-HM
	for netconf-archive@lists.ietf.org; Thu, 27 Apr 2006 10:41:27 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FZ7gL-0000fq-Tt
	for netconf-archive@lists.ietf.org; Thu, 27 Apr 2006 10:41:27 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FZ7bI-00084H-2c
	for netconf-data@psg.com; Thu, 27 Apr 2006 14:36: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.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FZ7bG-000844-Gm
	for netconf@ops.ietf.org; Thu, 27 Apr 2006 14:36:10 +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 k3REa9x8008982
	for <netconf@ops.ietf.org>; Thu, 27 Apr 2006 10:36:09 -0400
Received: (qmail 17378 invoked by uid 78); 27 Apr 2006 14:35:29 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.68 with SMTP; 27 Apr 2006 14:35:29 -0000
Message-ID: <4450D6AA.2060004@andybierman.com>
Date: Thu, 27 Apr 2006 07:35:22 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Eduardo Cardona <e.cardona@CableLabs.com>
CC: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Notification Requirements Consensus Points
References: <5259D0D7419C6149B347837A2E64F46F01856A59@srvxchg.cablelabs.com>
In-Reply-To: <5259D0D7419C6149B347837A2E64F46F01856A59@srvxchg.cablelabs.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: 187ae6c2eea74946c0ab707161f6256d

Eduardo Cardona wrote:
> See inline
> 
> 
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com] 
> Sent: Wednesday, April 26, 2006 10:36 AM
> To: Eduardo Cardona
> Cc: Netconf (E-mail)
> Subject: Re: Notification Requirements Consensus Points


As Phil pointed out, half the capabilities are used
to expose the native interface (e.g., distinct-startup or candidate).
The other half are used to separate complex features that
are clearly needed by larger devices (e.g., xpath).

I don't agree that mixed-mode is no problem for the agent to
dump notifications into the same channel.   IMO, this does
make agent implementation more complicated, and will introduce
interoperability problems because every vendor will handle
the undocumented complexities differently (such as prioritizing
notification over rpc-reply, dropping unsent messages).
Unlike Phil's simple "endless-RPC" approach, mixed-mode
would add an extra layer of resource contention in the agent.

You say you are "sensitive as well of vertical solutions as well
and vendor differentiation options."  I'm not sure what this means
in terms of the proposed feature set for netconf notifications.

Vendors can always add their own capabilities and extensions.
That doesn't change for notifications.  This is also by design!
We should make the standard as simple and useful as possible.
(This involves engineering trade-offs as usual.)  Then let vendors
add complicated extensions, instead of the WG!  If some
extensions are found by the WG to be useful in real networks,
they can be standardized later.



Andy


> 
> Eduardo Cardona wrote:
>> Hi, 
>> I am not a WG contributor, but I follow with interest the discussions.
>>
>> "There does not seem to be consensus on these points:
>> ...
>> - RPC operations and notifications should be mixed on the same
> session"
>>
>> I can see pros and cons for the implementation as already stated by
> the
>> WG. One thing is what the architecture should be, one is what works,
>> scale, is deployed and sold. Where the line is set? 
>>
>> My question is more Where IETF is moving on session/applications from
>> the transport protocol perspective? And plug the applications
> protocols
>> right there.
>>
>> For example : 
>> BEEP offers channels;  SCTP ( not a protocol required for Net-Conf)
>> offers streams within an association (session). 
>> What about Netconf for wireless/Satellite/slow/far networks where
> mixed
>> RPCs and large RPCs maybe a problem? 
>>
>> A compromised solution could be to define for BEEP the notification
>> channel and the configuration channel. SSH/SOAP (TCP) a negotiable
>> feature:
>> - Require for the Managed element to support both (in session and
>> different session notifications) 
>> - Require for the Manager ( the TCP session resources constrained
>> device) to support either one or the other, or both. 
>>
>> In this way the specialization is performed at the manager based on
> the
>> needs, and not at the network element
> 
> We already have plenty of options (i.e., capabilities).
> None of them are specific to any transport layer -- by design.
> The WG already rejected the idea of different notifications
> (and control channels, etc.) for each transport.
> 
> The netconf architecture only works if each layer hides the
> layer underneath it.  Is this feature important enough
> to incur the complexity it would cost to support it
> on all transports, mandatory in all agent implementations?
> 
> 
> <edo>
> As a closure note ( this item is tangential to the discussion) this
> layer separation I believe is a TCP paradigm. My point is that the rich
> features of the transport models are to be used by the applications for
> performance and robustness. This applies to management protocols as well
> - and a clean solution I believe for the "inline" notifications
> (mix-mode) e.g. BEEP channels - 
> 
> However, clean is never free.
> 
> Otherwise, IMO mix-mode has architecture contradictions beyond TCP.
> I don't necessarily share that netconf need to be connection-oriented
> transport agnostic beyond TCP
> 
> - I guess is more a matter of IETF direction for next generation
> applications. 
> </edo>
> 
> IMO, we are close to deciding that mixed-mode (what I call
> sharing 1 NETCONF session for notifications and operations)
> is not important to enough people to support.
> 
> Your proposal sounds like you don't want to mix notifications
> and operations together, but if other people to, then here is
> a way to do that.  Is that correct?
> 
> <edo>
> Yes that's the idea, 
> If the "inline" notifications (mix-mode) is supported, I think is easy
> for the managed device to dump the notifications in the same session but
> at discretion of the manager willingness to handle that burden, and the
> manager decides the model during the notification subscription process.
> 
> As I said, I prefer the separation of channels for Notifications and
> Configuration. 
> 
> But I am sensitive as well of vertical solutions as well and vendor
> differentiation options.  
> 
> However, the "inline" processing of messages is what I see a
> perpetuation of old application development models like CLI expect
> command processing - pointing to the CLI use case you mentioned below- ,
> rather than OO event driven models. That's where IMO the mix-mode
> feature hurts the architecture of the protocol for the next 10-20 years
> of its life time. The transport model capability I mentioned, provides
> mechanisms to evolve the protocol itself to new applications models.
> </edo>
> 
> I would like to see emails that clearly state
> "we have this requirement in our product/service/network"
> for specific features", or "we do not plan to use feature X".
> 
> The only example of mixed mode that has been given is
> the ability for current CLI implementations to be configured to
> send spurious system console messages to the terminal.
> I don't see how that really applies to a programmatic
> interface like NETCONF.  The messages can be much larger,
> and the interactions more complicated in NETCONF.
> 
> <edo>
> Agree
> </edo>
> 
>>
>> Although my preference is separate sessions (e.g BEEP channels, TCP
>> sessions) -> SCTP streams !  - solve the architecture paradigm (is
> there
>> any?) 
>>
>> Thanks
>>
>> Eduardo
> 
> Andy
> 
>> -----Original Message-----
>> From: Andy Bierman [mailto:ietf@andybierman.com] 
>> Sent: Wednesday, April 12, 2006 6:16 PM
>> To: Netconf (E-mail)
>> Subject: Notification Requirements Consensus Points
>>
>> Hi,
>>
>> It is difficult to measure WG consensus.
>> It seems like no matter what the issue is,
>> there are about equal numbers of opinions on either side.
>>
>> There seems to be consensus on these points:
>>  - Top level message is <notification> (rpc-one-way is out)
>>  - Separation of header and content-independent data is needed
>>  - Both the manager subscription model and traditional
> agent-configured
>>    notification generator model should be supported
>>  - The header should include some type of classification
>>    (e.g., event-class). 
>>  - The ability to filter (i.e., drop) notifications at the source
>>    based on event class and notification data content is needed. 
>>    Access control is impacted by this feature.
>>  - Named profiles (if kept) need to be fully specified in a
>>    standard read-create data model.
>>  - There is no limit on the length of the notification data
>>    (same as for RPC data)
>>
>> There does not seem to be consensus on these points:
>>  - The specific role of notifications in the netconf protocol
>>    or whether a specific role is even needed
>>  - The use of a read-only instead of a read-create data model
>>    for notification generation parameters
>>  - The use of specialized RPCs instead of a standard data model
>>    to configure notification generation parameters
>>  - The need for named profiles (issue is irrelevant if read-create
>>    data model approach is used)
>>  - Multiple subscriptions per session are needed
>>  - RPC operations and notifications should be mixed on the same
> session
>>  - The specific list of event classes, or
>>    whether this document or IANA maintains the list, or
>>    whether we even need a list at all (i.e., just a string match).
>>  - The need for a modify-subscription feature
>>    (Note that this is implicitly supported by edit-config if a
>>    read-create data model is used)
>>  - The use of an endless-RPC model (which is only relevant if
>>    the WG decides mixed-mode sessions are not required)
>>  - The specific standard notifications (if any) that an agent
>>    must support
>>
>>
>>
>> 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 Thu Apr 27 17:29:43 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FZE3T-00079d-Cj
	for netconf-archive@lists.ietf.org; Thu, 27 Apr 2006 17:29:43 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FZE3S-0003wD-Od
	for netconf-archive@lists.ietf.org; Thu, 27 Apr 2006 17:29:43 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FZDwv-000Hw5-3d
	for netconf-data@psg.com; Thu, 27 Apr 2006 21:22: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 [192.160.73.61] (helo=ondar.cablelabs.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <e.cardona@CableLabs.com>)
	id 1FZDwt-000Hvi-ML
	for netconf@ops.ietf.org; Thu, 27 Apr 2006 21:22:55 +0000
Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20])
	by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k3RLMmc3002595;
	Thu, 27 Apr 2006 15:22:48 -0600 (MDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Notification Requirements Consensus Points
Date: Thu, 27 Apr 2006 15:22:47 -0600
Message-ID: <5259D0D7419C6149B347837A2E64F46F018DCDF0@srvxchg.cablelabs.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notification Requirements Consensus Points
Thread-Index: AcZqB+/SRmCyO7lMQR67Ga2Lnf2DLgANDYHQ
From: "Eduardo Cardona" <e.cardona@CableLabs.com>
To: "Andy Bierman" <ietf@andybierman.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
X-Approved: ondar
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7

I see your points, I don't disagree to them,=20

I think you just pointed why mixed-mode RPCs won't play well or side
effects are unknown at this point.=20


BEEP Channels are not an option by initial constraints of the WG; -
though a clean architecture approach -However, It has no equivalent
counterpart for TCP transports other than separate sessions. From that
line, that's were my preferred option of separate sessions came anyways.


Then, I agree with you to keep it simple=20

Constrained but correct rather than flexible but buggy.

Thanks

Eduardo=20



-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]=20
Sent: Thursday, April 27, 2006 8:35 AM
To: Eduardo Cardona
Cc: Netconf (E-mail)
Subject: Re: Notification Requirements Consensus Points

Eduardo Cardona wrote:
> See inline
>=20
>=20
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com]=20
> Sent: Wednesday, April 26, 2006 10:36 AM
> To: Eduardo Cardona
> Cc: Netconf (E-mail)
> Subject: Re: Notification Requirements Consensus Points


As Phil pointed out, half the capabilities are used
to expose the native interface (e.g., distinct-startup or candidate).
The other half are used to separate complex features that
are clearly needed by larger devices (e.g., xpath).

I don't agree that mixed-mode is no problem for the agent to
dump notifications into the same channel.   IMO, this does
make agent implementation more complicated, and will introduce
interoperability problems because every vendor will handle
the undocumented complexities differently (such as prioritizing
notification over rpc-reply, dropping unsent messages).
Unlike Phil's simple "endless-RPC" approach, mixed-mode
would add an extra layer of resource contention in the agent.

You say you are "sensitive as well of vertical solutions as well
and vendor differentiation options."  I'm not sure what this means
in terms of the proposed feature set for netconf notifications.

Vendors can always add their own capabilities and extensions.
That doesn't change for notifications.  This is also by design!
We should make the standard as simple and useful as possible.
(This involves engineering trade-offs as usual.)  Then let vendors
add complicated extensions, instead of the WG!  If some
extensions are found by the WG to be useful in real networks,
they can be standardized later.



Andy


>=20
> Eduardo Cardona wrote:
>> Hi,=20
>> I am not a WG contributor, but I follow with interest the
discussions.
>>
>> "There does not seem to be consensus on these points:
>> ...
>> - RPC operations and notifications should be mixed on the same
> session"
>>
>> I can see pros and cons for the implementation as already stated by
> the
>> WG. One thing is what the architecture should be, one is what works,
>> scale, is deployed and sold. Where the line is set?=20
>>
>> My question is more Where IETF is moving on session/applications from
>> the transport protocol perspective? And plug the applications
> protocols
>> right there.
>>
>> For example :=20
>> BEEP offers channels;  SCTP ( not a protocol required for Net-Conf)
>> offers streams within an association (session).=20
>> What about Netconf for wireless/Satellite/slow/far networks where
> mixed
>> RPCs and large RPCs maybe a problem?=20
>>
>> A compromised solution could be to define for BEEP the notification
>> channel and the configuration channel. SSH/SOAP (TCP) a negotiable
>> feature:
>> - Require for the Managed element to support both (in session and
>> different session notifications)=20
>> - Require for the Manager ( the TCP session resources constrained
>> device) to support either one or the other, or both.=20
>>
>> In this way the specialization is performed at the manager based on
> the
>> needs, and not at the network element
>=20
> We already have plenty of options (i.e., capabilities).
> None of them are specific to any transport layer -- by design.
> The WG already rejected the idea of different notifications
> (and control channels, etc.) for each transport.
>=20
> The netconf architecture only works if each layer hides the
> layer underneath it.  Is this feature important enough
> to incur the complexity it would cost to support it
> on all transports, mandatory in all agent implementations?
>=20
>=20
> <edo>
> As a closure note ( this item is tangential to the discussion) this
> layer separation I believe is a TCP paradigm. My point is that the
rich
> features of the transport models are to be used by the applications
for
> performance and robustness. This applies to management protocols as
well
> - and a clean solution I believe for the "inline" notifications
> (mix-mode) e.g. BEEP channels -=20
>=20
> However, clean is never free.
>=20
> Otherwise, IMO mix-mode has architecture contradictions beyond TCP.
> I don't necessarily share that netconf need to be connection-oriented
> transport agnostic beyond TCP
>=20
> - I guess is more a matter of IETF direction for next generation
> applications.=20
> </edo>
>=20
> IMO, we are close to deciding that mixed-mode (what I call
> sharing 1 NETCONF session for notifications and operations)
> is not important to enough people to support.
>=20
> Your proposal sounds like you don't want to mix notifications
> and operations together, but if other people to, then here is
> a way to do that.  Is that correct?
>=20
> <edo>
> Yes that's the idea,=20
> If the "inline" notifications (mix-mode) is supported, I think is easy
> for the managed device to dump the notifications in the same session
but
> at discretion of the manager willingness to handle that burden, and
the
> manager decides the model during the notification subscription
process.
>=20
> As I said, I prefer the separation of channels for Notifications and
> Configuration.=20
>=20
> But I am sensitive as well of vertical solutions as well and vendor
> differentiation options. =20
>=20
> However, the "inline" processing of messages is what I see a
> perpetuation of old application development models like CLI expect
> command processing - pointing to the CLI use case you mentioned below-
,
> rather than OO event driven models. That's where IMO the mix-mode
> feature hurts the architecture of the protocol for the next 10-20
years
> of its life time. The transport model capability I mentioned, provides
> mechanisms to evolve the protocol itself to new applications models.
> </edo>
>=20
> I would like to see emails that clearly state
> "we have this requirement in our product/service/network"
> for specific features", or "we do not plan to use feature X".
>=20
> The only example of mixed mode that has been given is
> the ability for current CLI implementations to be configured to
> send spurious system console messages to the terminal.
> I don't see how that really applies to a programmatic
> interface like NETCONF.  The messages can be much larger,
> and the interactions more complicated in NETCONF.
>=20
> <edo>
> Agree
> </edo>
>=20
>>
>> Although my preference is separate sessions (e.g BEEP channels, TCP
>> sessions) -> SCTP streams !  - solve the architecture paradigm (is
> there
>> any?)=20
>>
>> Thanks
>>
>> Eduardo
>=20
> Andy
>=20
>> -----Original Message-----
>> From: Andy Bierman [mailto:ietf@andybierman.com]=20
>> Sent: Wednesday, April 12, 2006 6:16 PM
>> To: Netconf (E-mail)
>> Subject: Notification Requirements Consensus Points
>>
>> Hi,
>>
>> It is difficult to measure WG consensus.
>> It seems like no matter what the issue is,
>> there are about equal numbers of opinions on either side.
>>
>> There seems to be consensus on these points:
>>  - Top level message is <notification> (rpc-one-way is out)
>>  - Separation of header and content-independent data is needed
>>  - Both the manager subscription model and traditional
> agent-configured
>>    notification generator model should be supported
>>  - The header should include some type of classification
>>    (e.g., event-class).=20
>>  - The ability to filter (i.e., drop) notifications at the source
>>    based on event class and notification data content is needed.=20
>>    Access control is impacted by this feature.
>>  - Named profiles (if kept) need to be fully specified in a
>>    standard read-create data model.
>>  - There is no limit on the length of the notification data
>>    (same as for RPC data)
>>
>> There does not seem to be consensus on these points:
>>  - The specific role of notifications in the netconf protocol
>>    or whether a specific role is even needed
>>  - The use of a read-only instead of a read-create data model
>>    for notification generation parameters
>>  - The use of specialized RPCs instead of a standard data model
>>    to configure notification generation parameters
>>  - The need for named profiles (issue is irrelevant if read-create
>>    data model approach is used)
>>  - Multiple subscriptions per session are needed
>>  - RPC operations and notifications should be mixed on the same
> session
>>  - The specific list of event classes, or
>>    whether this document or IANA maintains the list, or
>>    whether we even need a list at all (i.e., just a string match).
>>  - The need for a modify-subscription feature
>>    (Note that this is implicitly supported by edit-config if a
>>    read-create data model is used)
>>  - The use of an endless-RPC model (which is only relevant if
>>    the WG decides mixed-mode sessions are not required)
>>  - The specific standard notifications (if any) that an agent
>>    must support
>>
>>
>>
>> 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/>
>>
>>
>>
>>
>=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/>



From owner-netconf@ops.ietf.org Fri Apr 28 08:09:20 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FZRmi-0003ri-Hf
	for netconf-archive@lists.ietf.org; Fri, 28 Apr 2006 08:09:20 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FZRmh-0005Gu-8V
	for netconf-archive@lists.ietf.org; Fri, 28 Apr 2006 08:09:20 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FZRhJ-00071P-6J
	for netconf-data@psg.com; Fri, 28 Apr 2006 12:03: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.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 1FZRhI-00070U-5E
	for netconf@ops.ietf.org; Fri, 28 Apr 2006 12:03:44 +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 k3SC3dH06249
	for <netconf@ops.ietf.org>; Fri, 28 Apr 2006 08:03:40 -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: Notification Requirements Consensus Points
Date: Fri, 28 Apr 2006 08:03:36 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B408254D06@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notification Requirements Consensus Points
Thread-Index: AcZpUHRMINCSmvUtSue7NHikFIkD2ABau5zg
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

<Andy>
I would like to see emails that clearly state
"we have this requirement in our product/service/network"
for specific features", or "we do not plan to use feature X".

The only example of mixed mode that has been given is
the ability for current CLI implementations to be configured to send
spurious system console messages to the terminal. I don't see how that
really applies to a programmatic interface like NETCONF.  The messages
can be much larger, and the interactions more complicated in NETCONF.

</Andy>

Actually, there have been a lot more examples use cases given, but the
CLI one is an example of a well-deployed solution that certain people
really like.

Other use cases are the ability to modify, add or remove subscriptions
from the same session as you are receiving notifications from. I believe
there have been others mentioned as well.

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 Fri Apr 28 14:38:56 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FZXrk-000331-MW
	for netconf-archive@lists.ietf.org; Fri, 28 Apr 2006 14:38:56 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FZXrj-0003Zp-Ad
	for netconf-archive@lists.ietf.org; Fri, 28 Apr 2006 14:38:56 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FZXm5-0007JG-IE
	for netconf-data@psg.com; Fri, 28 Apr 2006 18:33: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.52] (helo=ns-omrbm2.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FZToO-000GMY-K5
	for netconf@ops.ietf.org; Fri, 28 Apr 2006 14:19:13 +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 k3SEJ9gf020640
	for <netconf@ops.ietf.org>; Fri, 28 Apr 2006 10:19:12 -0400
Received: (qmail 5998 invoked by uid 78); 28 Apr 2006 14:19:09 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.65 with SMTP; 28 Apr 2006 14:19:09 -0000
Message-ID: <445224D1.4080807@andybierman.com>
Date: Fri, 28 Apr 2006 07:21:05 -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: manager subscription model for notifications: usage survey
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: 97adf591118a232206bdb5a27b217034

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.

Who is using this model today?
What products work this way today?

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 subscriptions instead.

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?

If this subscribe-only model is not being used in a meaningful
way in the real world, then I don't understand why we need
to standardize it at all.


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 Apr 28 14:55:43 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FZY7y-0004DF-Vb
	for netconf-archive@lists.ietf.org; Fri, 28 Apr 2006 14:55:42 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FZY7y-000447-Hd
	for netconf-archive@lists.ietf.org; Fri, 28 Apr 2006 14:55:42 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FZY56-0008eF-MJ
	for netconf-data@psg.com; Fri, 28 Apr 2006 18:52: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.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 1FZY55-0008dk-K6
	for netconf@ops.ietf.org; Fri, 28 Apr 2006 18:52:43 +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 k3SIqdH24767
	for <netconf@ops.ietf.org>; Fri, 28 Apr 2006 14:52:39 -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: Fri, 28 Apr 2006 14:52:38 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4082BBB6C@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: manager subscription model for notifications: usage survey
Thread-Index: AcZq8z3lvTXSJfeSTqyZm5jHVJZmmAAANMuA
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: c0bedb65cce30976f0bf60a0a39edea4

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.

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 different
behaviour meant to handle the call-home cases. I don't expect this to be
the method generally used since the normal subscription is much more
predictable and reliable, but as people have indicated there are cases
when you need to reverse roles.

Sharon

-----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:21 AM
To: Netconf (E-mail)
Subject: manager subscription model for notifications: usage survey


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.

Who is using this model today?
What products work this way today?

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
subscriptions instead.

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?

If this subscribe-only model is not being used in a meaningful way in
the real world, then I don't understand why we need to standardize it at
all.


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 Apr 28 15:34:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FZYjL-0004UI-C9
	for netconf-archive@lists.ietf.org; Fri, 28 Apr 2006 15:34:19 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FZYjH-0006v1-Sf
	for netconf-archive@lists.ietf.org; Fri, 28 Apr 2006 15:34:19 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FZYeK-000BKq-Li
	for netconf-data@psg.com; Fri, 28 Apr 2006 19:29: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 1FZYeH-000BKb-Bz
	for netconf@ops.ietf.org; Fri, 28 Apr 2006 19:29:05 +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 k3SJT2hn005022
	for <netconf@ops.ietf.org>; Fri, 28 Apr 2006 15:29:03 -0400
Received: (qmail 28589 invoked by uid 78); 28 Apr 2006 19:29:02 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.66 with SMTP; 28 Apr 2006 19:29:02 -0000
Message-ID: <44526CDA.2030908@andybierman.com>
Date: Fri, 28 Apr 2006 12:28:26 -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: 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
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2

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 understand what the draft says.
It's all the details (like interaction with other
notification management systems and scaling issues),
that are not in the draft that are causing me concern.


> 
> 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 different
> behaviour meant to handle the call-home cases. I don't expect this to be
> the method generally used since the normal 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.


> 
> Sharon

Andy


> 
> -----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:21 AM
> To: Netconf (E-mail)
> Subject: manager subscription model for notifications: usage survey
> 
> 
> 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.
> 
> Who is using this model today?
> What products work this way today?
> 
> 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
> subscriptions instead.
> 
> 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?
> 
> If this subscribe-only model is not being used in a meaningful way in
> the real world, then I don't understand why we need to standardize it at
> all.
> 
> 
> 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 Fri Apr 28 15:53:33 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FZZ1x-00079D-5Z
	for netconf-archive@lists.ietf.org; Fri, 28 Apr 2006 15:53:33 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FZZ1v-0007vK-Jw
	for netconf-archive@lists.ietf.org; Fri, 28 Apr 2006 15:53:33 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FZYyg-000CnI-Ep
	for netconf-data@psg.com; Fri, 28 Apr 2006 19:50:10 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO,
	MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1
Received: from [209.173.53.84] (helo=willow.neustar.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from <ietf@ietf.org>)
	id 1FZYyf-000Cn5-M9
	for netconf@ops.ietf.org; Fri, 28 Apr 2006 19:50:09 +0000
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10])
	by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k3SJo19W006187
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Apr 2006 19:50:01 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1FZYyX-0007Wj-LM; Fri, 28 Apr 2006 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: netconf@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-netconf-notification-01.txt 
Message-Id: <E1FZYyX-0007Wj-LM@stiedprstage1.ietf.org>
Date: Fri, 28 Apr 2006 15:50:01 -0400
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration Working Group of the IETF.

	Title		: NETCONF Event Notifications
	Author(s)	: S. Chisholm, et al.
	Filename	: draft-ietf-netconf-notification-01.txt
	Pages		: 53
	Date		: 2006-4-28
	
This memo defines a framework for sending asynchronous messages, or
   event notifications in NETCONF.  It defines both the operations
   necessary to support this concept, and also discusses implications
   for the mapping to application protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-netconf-notification-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-netconf-notification-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2006-4-28143630.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-netconf-notification-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-netconf-notification-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2006-4-28143630.I-D@ietf.org>

--OtherAccess--

--NextPart--

--
to 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 Apr 28 16:07:18 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FZZFG-0002HZ-32
	for netconf-archive@lists.ietf.org; Fri, 28 Apr 2006 16:07:18 -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 1FZYNc-0005Ll-Tm
	for netconf-archive@lists.ietf.org; Fri, 28 Apr 2006 15:11:52 -0400
Received: from psg.com ([147.28.0.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FZYEf-0004hi-GG
	for netconf-archive@lists.ietf.org; Fri, 28 Apr 2006 15:02:40 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FZYBj-0009Ev-S7
	for netconf-data@psg.com; Fri, 28 Apr 2006 18:59: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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.1
Received: from [207.17.137.119] (helo=borg.juniper.net)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <kwatsen@juniper.net>)
	id 1FZYBj-0009Ei-58
	for netconf@ops.ietf.org; Fri, 28 Apr 2006 18:59:35 +0000
Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109])
  by borg.juniper.net with ESMTP; 28 Apr 2006 11:59:34 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.04,164,1144047600"; 
   d="scan'208"; a="546735250:sNHT93587036"
Received: from antitop.jnpr.net ([172.24.15.27]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 28 Apr 2006 11:59:33 -0700
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Notification Requirements Consensus Points
Date: Fri, 28 Apr 2006 11:59:32 -0700
Message-ID: <B8C821F9E0675D44BFA994C28C0120E5E2512E@antitop.jnpr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notification Requirements Consensus Points
Thread-Index: AcZqB+/SRmCyO7lMQR67Ga2Lnf2DLgANDYHQAC2kdXA=
From: "Kent Watsen" <kwatsen@juniper.net>
To: "Eduardo Cardona" <e.cardona@CableLabs.com>,
	"Andy Bierman" <ietf@andybierman.com>
Cc: "Netconf \(E-mail\)" <netconf@ops.ietf.org>
X-OriginalArrivalTime: 28 Apr 2006 18:59:34.0071 (UTC) FILETIME=[E35D4470:01C66AF5]
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f



Eduardo Cardona wrote:
> BEEP Channels are not an option by initial constraints of the WG; -
> though a clean architecture approach -However, It has no equivalent
> counterpart for TCP transports other than separate sessions. From that
> line, that's were my preferred option of separate sessions came
anyways.

Actually, SSH already supports channels in a way that is almost
identical to BEEP - only SOAP doesn't have native channeling...

Kent

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



From owner-netconf@ops.ietf.org Fri Apr 28 21:23:01 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FZeAn-0005tf-Dj
	for netconf-archive@lists.ietf.org; Fri, 28 Apr 2006 21:23:01 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FZeAm-0001ut-UG
	for netconf-archive@lists.ietf.org; Fri, 28 Apr 2006 21:23:01 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from <owner-netconf@ops.ietf.org>)
	id 1FZe44-0008rB-J8
	for netconf-data@psg.com; Sat, 29 Apr 2006 01:16: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.55] (helo=ns-omrbm5.netsolmail.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <ietf@andybierman.com>)
	id 1FZe42-0008qk-TC
	for netconf@ops.ietf.org; Sat, 29 Apr 2006 01:16:03 +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 k3T1G2Sw003520
	for <netconf@ops.ietf.org>; Fri, 28 Apr 2006 21:16:02 -0400
Received: (qmail 22387 invoked by uid 78); 29 Apr 2006 01:16:01 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237)
  by 10.49.36.68 with SMTP; 29 Apr 2006 01:16:01 -0000
Message-ID: <4452BDF9.8080506@andybierman.com>
Date: Fri, 28 Apr 2006 18:14:33 -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: [Fwd: I-D ACTION:draft-ietf-netconf-notification-01.txt]
Content-Type: multipart/mixed;
 boundary="------------050208000704010209040408"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7

This is a multi-part message in MIME format.
--------------050208000704010209040408
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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


--------------050208000704010209040408
Content-Type: message/rfc822;
 name="I-D ACTION:draft-ietf-netconf-notification-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D ACTION:draft-ietf-netconf-notification-01.txt"

X-Account-Key: account4
Return-Path: <i-d-announce-bounces@ietf.org>
Delivered-To: ietf@6908.7081
Received: (qmail 5311 invoked by uid 78); 28 Apr 2006 21:19:31 -0000
Received: from unknown (HELO ns-mr7.netsolmail.com) (205.178.149.7)
  by 10.49.37.6 with SMTP; 28 Apr 2006 21:19:31 -0000
Received: from megatron.ietf.org (optimus.ietf.org [156.154.16.145])
	by ns-mr7.netsolmail.com (8.13.6/8.13.6) with ESMTP id k3SLJQV8012186
	for <ietf@andybierman.com>; Fri, 28 Apr 2006 17:19:31 -0400
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FZaN1-0005Vo-JM; Fri, 28 Apr 2006 17:19:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FZaMz-0005T2-EZ
	for i-d-announce@ietf.org; Fri, 28 Apr 2006 17:19:21 -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 1FZZ8u-0008Q2-O5
	for i-d-announce@ietf.org; Fri, 28 Apr 2006 16:00:44 -0400
Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129]
	helo=willow.neustar.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FZYyY-0005Qh-0r
	for i-d-announce@ietf.org; Fri, 28 Apr 2006 15:50:08 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10])
	by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k3SJo19W006187
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Apr 2006 19:50:01 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1FZYyX-0007Wj-LM; Fri, 28 Apr 2006 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1FZYyX-0007Wj-LM@stiedprstage1.ietf.org>
Date: Fri, 28 Apr 2006 15:50:01 -0400
X-Spam-Score: -5.9 (-----)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: netconf@ops.ietf.org
Subject: I-D ACTION:draft-ietf-netconf-notification-01.txt 
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: internet-drafts@ietf.org
List-Id: i-d-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:i-d-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
List-Post: <mailto:i-d-announce@ietf.org>
List-Help: <mailto:i-d-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:i-d-announce-request@ietf.org?subject=subscribe>
Errors-To: i-d-announce-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration Working Group of the IETF.

	Title		: NETCONF Event Notifications
	Author(s)	: S. Chisholm, et al.
	Filename	: draft-ietf-netconf-notification-01.txt
	Pages		: 53
	Date		: 2006-4-28
	
This memo defines a framework for sending asynchronous messages, or
   event notifications in NETCONF.  It defines both the operations
   necessary to support this concept, and also discusses implications
   for the mapping to application protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-netconf-notification-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-netconf-notification-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-4-28143630.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-netconf-notification-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-netconf-notification-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-4-28143630.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--




--------------050208000704010209040408--

--
to 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/>