Subject: Update to Netconf Notifications Draft

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 22 Jun 2006 09:20:57 -0400

hi

I have submitted the updated Netconf Event Notification Draft. There
appears to be a problem with my website, so I can't post a version for
people to read while waiting for real one. When the site is back up,
I'll make a copy available.

The update is as promised in the emails I sent with the proposed
updates, with the following exceptions

1. I was hoping for some specific inputs to help flesh out the call home
section but didn't receive it. These changes will have to wait for the
next version.

2. I had said we would clarify that the filters would be applied against
the content of the filters but when I went to make the change I realized
the intention was that filters were applied against the notification
itself, not the content. By this I mean that either through sub tree of
XPath the element that defines the notification has a handle that we can
use for filtering against the notification. I've added clarification
around that instead, but in hindsight perhaps I could have explained it
better.

3. It was suggested that instead of spreading the examples throughout
the document that they get co-located in the document. In thinking about
this more, I think it is useful to have examples in-line to help explain
various ideas. This would not preclude having a more comprehensive
example section though.

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

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

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 22 Jun 2006 13:31:29 -0400

hi

The draft can now we found at
	
http://standards.nortel.com/netconf/docs/netconfEvent/pre_02-netconf-not
ification.txt

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Chisholm, Sharon [CAR:ZZ00:EXCH]
Sent: Thursday, June 22, 2006 9:21 AM
To: [email-masked]
Subject: Update to Netconf Notifications Draft

hi

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 26 Jun 2006 17:42:16 +0200 (CEST)

Hi,

A comment on section 3.8, interleaving messages.

Suppose the manager sends a large copy-config and at the same time the
agent sends a large notification.  If care is not taken, the write()
call on each side can block, and we would get deadlock.  To avoid
this, the manager and/or agent could be required to use non-blocking
io, and - while writing the large message - read from the session and
buffer internally.  Alternatively, the agent could use two threads.

Should any of this be specified?  Does a client application which
supports interleaving messages have to use non-blocking io in order to
be compliant (or should the agent handle this)?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 26 Jun 2006 10:06:40 -0700

> A comment on section 3.8, interleaving messages.

The larger issue that is still unresolved is how
important this feature is to have.  The extended RPC
approach is much simpler, at the cost of the resources
for an additional session.  The extended RPC approach
is also much better for the 'ping' scenario than
a special notification type for 'RPC reply'.

We still have a high-level disagreement on the relative
engineering cost trade-offs of using 2 sessions vs. sharing
1 session for operations and notifications.

IMO, we are pretty far from a clean standard.
The eventual solution will need to provide for
proper standard read-create data models, specify
a reasonable architecture and security model,
and be as simple as possible, with a small number
of options.

We also need to explain why it is so important that
the NMS get copies of notifications in NETCONF sessions,
as opposed to using a mgr-2-mgr API to get the same information
from a notification receiver application (e.g., syslog +
SNMP trap server).

Some people have also suggested that we explain in the RFC
why a special NETCONF notification system is needed
in order to solve the network configuration problem.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 26 Jun 2006 21:37:23 +0200 (CEST)

> a special notification type for 'RPC reply'.

Altough I personally prefer the endless RPC model for events, I don't
think it's "much simpler", at least not from an implementation point
of view.  The agent side might be simpler in some case (e.g. it
doesn't have to deal with a modify command), but on the other hand the
manager side needs to synchronize events if it wants to emulate a
modify operation.

Also, even if the model in Sharon's draft is used for events, the
endless RPC can still be used for ping-like commands.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 26 Jun 2006 14:14:45 -0700

> manager side needs to synchronize events if it wants to emulate a

The manager has to synch notifications to operations
using 2 or 3 different protocols now.  I am talking
about 2 sessions of the same protocol instead.

It is true that the manager design has to allow for more than
one active session per agent.  This doesn't seem much harder
than allowing for more than one active session (to
different agents).

The agent already has code to keep multiple sessions from
stepping on each other.  For mixed-mode, it needs additional
code to provide the same sort of safeguards within a session
as well.

I changed the name from "endless RPC" to "extended RPC"
because it does end if so requested.

BTW, there is absolutely no difference at all from
a NMS implementation POV, between an agent that is
sending an extended rpc-reply (e.g., <notification>
element sent as needed) and an agent that is sending
the contents of a <get> reply      really,    really,   slowly....

There is no requirement at all that any portion of a
NETCONF PDU be transmitted within a certain period of time.
Managers and agents need to deal with this fact.

> endless RPC can still be used for ping-like commands.

Yes, you can already do this -- without changing a single
word in the NETCONF spec.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 26 Jun 2006 17:24:50 -0400

[back from vacation and kickstarting my brain (putt, putt)]

>and be as simple as possible, with a small number

With the exception of the create (.vs. write?) data model, I think
I cover most of this.  What are you looking for wrt the security
model?  Security of the content of the data (permission to see bgp
peer information) or just security of the data as a whole (as covered
by the transport protocol)?

>from a notification receiver application (e.g., syslog +

Syslog and snmp are traditionally preconfigured, with the device
knowing (from config) who to aim notifications at.  This works
well in traditional environments but breaks in the "pop open my
laptop and run my application locally" world.  When configuring
a device, access to the notifications it is sending gives valuable
information about the state of the box, what's going on, and what
you just broke.  Being able to see this in your application (and
being able to react to it automatically) is a win.

I have some words about this in the draft; do I need more?

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 27 Jun 2006 13:28:35 -0400

>because it does end if so requested.

I called them long-lived RPCs in the draft, which seems fairly
accurate.

>word in the NETCONF spec.

I think this is the big difference between the drafts.  Use the
existing netconf RPC mechanism to deliver existing syslog data
versus use a new mechanism to delivery new content.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 27 Jun 2006 10:35:35 -0700

> versus use a new mechanism to delivery new content.

Agree 110% !!!
I would even say that it is Bad Engineering
to invent new mechanisms when the existing mechanisms
will do the job.

Andy