Subject: no interim meeting -- read the rules

From: Andy Bierman <[email-masked]>
Date: Tue, 28 Mar 2006 09:05:00 -0800

Hi,

Here is the IESG rules on holding interim meetings:

http://www.ietf.org/IESG/STATEMENTS/Interim-meetings.txt

We can't have an interim meeting within 30 days before the IETF,
and we can't have one instead of our 2 hour slot just after
the IETF.

There is supposedly interest in the notification work.
I don't understand why most of these people have time
and money to go to an interim to work on this topic,
but they don't have time to read the draft and send comments
to the mailing list, or show up to the IETF meeting in Dallas
prepared to work on this document.

As Dan and Dave H. pointed out, we need to agree on what
we are doing and why we are doing it.  Several people
have told me (and mentioned on the list) that they
don't understand why we are reinventing syslog instead
of working on network configuration.

So let's write down all the reasons why we need notifications
in NETCONF, and why using or extending existing standards
instead won't work.

It doesn't really matter which parameters get passed
in the 'start-notifications' RPC if the entire work item
ends up in the dumpster, does it?

Andy

--
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: Andy Bierman <[email-masked]>
Date: Tue, 28 Mar 2006 09:27:19 -0800

> and we can't have one instead of our 2 hour slot just after

Actually our AD just informed me that he thinks it
would be okay to have the regular NETCONF session
on Friday morning, and then continue the interim
(for those who want to stay) until Sunday.

That is what we will plan to do. July 14-16 at the
IETF #66 hotel.

Thank you to everybody who offered to host the interim.
I hope you will show up in Montreal instead.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 29 Mar 2006 09:57:55 +0200

Hi,
For us notifications are needed mostly not as a logging mechanism but as:
- a way to notify about configuration changes
- a way to notify the management system about delayed results of an RPC (e.g. when an RPC 
initiated action takes 10 minutes to complete we send an immediate reply <started> and a 
late reply <finished>)
- to notify the network management system (NMS) about things that might need operator 
action. (While alarm handling is mostly SNMP there is a need for some other events to be 
handled by the NMS.)

For these reasons we do need a notification mechanism. We could use
- SNMP: but if we have an XML based hierarchical data model with meaningful names using 
SNMP is not my choice.
- Syslog: but the message size limit of less then 480 octets seems a problem. Also I like 
subscription. Adding XML to syslog needs some work. We have to care about a second 
transport/security mechanism TLS (I don't know if this is a real problem).
- Netconf-notifications: This would mean a somewhat unified structure within Netconf. 
Using our XML-based hierarchical data model would be natural.

regards Balazs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 29 Mar 2006 10:48:01 +0200

On Wed, Mar 29, 2006 at 09:57:55AM +0200, Balazs Lengyel wrote:

> - a way to notify the management system about delayed results of an RPC 
> (e.g. when an RPC initiated action takes 10 minutes to complete we send an 
> immediate reply <started> and a late reply <finished>)
> - to notify the network management system (NMS) about things that might 
> need operator action. (While alarm handling is mostly SNMP there is a need 
> for some other events to be handled by the NMS.)
> 
> 
> - SNMP: but if we have an XML based hierarchical data model with meaningful 
> names using SNMP is not my choice.
> - Syslog: but the message size limit of less then 480 octets seems a 
> problem. Also I like subscription. Adding XML to syslog needs some work. We 
> have to care about a second transport/security mechanism TLS (I don't know 
> if this is a real problem).
> - Netconf-notifications: This would mean a somewhat unified structure 
> within Netconf. Using our XML-based hierarchical data model would be 
> natural.

This is useful input.

In order to avoid a formal requirements document, I suggest we simply
collect motivations and requirements in an easy and simple online
format in one place until we believe we have something we can agree
on. I am willing to play the editor for this. I created an initial
wiki page:

http://www.ietf.org/html.charters/netconf-charter.html

Please send additions and clarifications (lets try to do some work in
the mailing list ;-).

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 29 Mar 2006 11:13:51 +0200

> Please send additions and clarifications (lets try to do some work in

It seems people are actually reading my emails. So here is the correct
URL:

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

I also have changed the subject just in case you feel you need to
reply to this message. :)

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 29 Mar 2006 16:49:19 +0200

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

If you want to add something to the motivation/requirements page,
please send email to the WG list and not to me directly. I will not
add something which is not posted as well to this list.

Consider myself a scribe who simply takes notes of the mailing list
discussion and the wiki page is simply my notepad that everyone can
see (and which tracks history).

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 29 Mar 2006 18:09:06 +0200

I believe the possibility to have a reliable transport of notifications is also a 
requirement. (Not just simple UDP without acknowledgment.)

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Wed, 29 Mar 2006 14:41:55 -0800

Balazs Lengyel wrote:
> (e.g. when an RPC initiated action takes 10 minutes to complete we send 
> an immediate reply <started> and a late reply <finished>)

When you explained this the first time it sounded like you
broke the RPC model, but you didn't.  Your 1st RFC can be
seen as a request to start a background task.  Exactly 1 rfc-reply
is sent for this request.  Later you send notifications to
provide status of the background task.  Looks like a good use
of notifications to me.

All of your use cases make sense I think.
You could probably do this with syslog or snmp notifications,
but it also makes sense to use netconf notifications.

Andy

> need operator action. (While alarm handling is mostly SNMP there is a 
> need for some other events to be handled by the NMS.)

> - SNMP: but if we have an XML based hierarchical data model with 
> meaningful names using SNMP is not my choice.
> problem. Also I like subscription. Adding XML to syslog needs some work. 
> We have to care about a second transport/security mechanism TLS (I don't 
> know if this is a real problem).

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 30 Mar 2006 12:33:47 +0200

----- Original Message -----
From: "Balazs Lengyel" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Cc: "Netconf (E-mail)" <[email-masked]>
Sent: Wednesday, March 29, 2006 9:57 AM
Subject: Re: no interim meeting -- read the rules

> - SNMP: but if we have an XML based hierarchical data model with meaningful
names using
> 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?

Agreeing with the reasons above why notifications are needed, I see this as the
reasonwhy they should be part of netconf.
If security is not needed, then no problem - lots of choice.

Tom Petch

<snip>