Subject: RE: Notification architecture

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 12 Jan 2006 10:33:54 -0500

hi

Couple points:

1. Notifications are not layered on the <rpc>, but rather a new wrapper
of <one-way-rpc> which is at the same Netconf layer as <rpc> but is
different. Therefore there should be no issues surrounding statistics
and I don't think the beep mapping is hindered by this wrapper.

2. I've had good success in using the existing Netconf layer model to
help people understand the different bits of Netconf. Your proposed
update solves one problem I had around the fact that drawn the wrong
way, it would imply that <notifications> ran over <rpc> or something
along those lines, but it now breaks the fact that there are layers.
This concept gets somewhat lost.

3. There are advantages to systems who want to process both synchronous
and asynchronous messages to be able to use the same method
	- process rpc
	- process message
By having two different architectures for these messages, things diverge
much more.

4. I don't understand the access control comment.

5. Layer compression for notifications limits future extensibility
options. What happens if some mythical day in the future we want to add
another type of asynchronous message, or want to do acknowledged events?
How does that work? Right now, I could conceive of running
<notification> over <rpc> <rpc-reply> as one method to do acknowledged
events, which becomes more difficult with what you are proposing. I
don't want to optimize the architecture for things that are out of scope
of this release and things which we may never ever get to, but I think
in general we should give some consideration to the implications on
extensibility that this compression might have.

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Andy Bierman
Sent: Thursday, January 12, 2006 9:59 AM
To: Netconf (E-mail)
Subject: Notification architecture

Hi,

IMO, the architectural layering defined in the Notifications draft is
broken.  Currently, a notification is modeled as an operation -- as a
child of the <rpc> node in the PDU encoding. The whole notion of a
one-way remote procedure call instead of an event notification seems
convoluted to me.  A notification is not a 'void' procedure call (i.e.,
just a function with no return value).  It has temporal characteristics.
That's why it has a timestamp and an RPC doesn't.

<notification> needs to be a top-level element.

This proposed layering creates several problems:

  - Access control configuration is more complicated.  It is
    desirable to give separate access to users for notifications
    and real RPCs like <edit-config>.  Nesting these elements
    forces more complex access control rules to be configured
    to accomplish this feature.
  - Notifications cannot be channelized in the BEEP transport
    unless <notification> is independent of <rpc>.  Obviously
    we want to take advantage of this feature in BEEP for asynch
    notifications.  That's been our design goal from day 1.
  - Statistics for RPCs will be confusing
    It is desirable for the stats for RPCs to be separate from
    the stats for notifications, e.g.
      ncInRpcs == ncOutNoErrs + ncOutErrs[ncErrorType];
      (for all ncErrorType)
  - Dual-role entities will be receiving <rpc> as a real RPC
    and as a notification.  This complicates the code path.
    Current implementations can set up internal structures
    and glean info from the 'rpc' node that is required
    for all real RPCs.  As proposed, an implementation would
    have to either look ahead or undo and restart, because
    the internal code path for notification processing
    is totally different than for a real RPC (no error response
    handling for starters).

Draft Proposed Layering:

                Layer                      Example
            +-------------+      +-----------------------------+
            |   Content   |      |     Configuration data      |
            +-------------+      +-----------------------------+
                   |                           |
            +-------------+      +-----------------------------+
            | Operations  |      | <get-config>, <notification>|
            +-------------+      +-----------------------------+
                   |                           |
            +-------------+      +-----------------------------+
            |     RPC     |      |    <rpc>, <rpc-reply>       |
            +-------------+      +-----------------------------+
                   |                           |
            +-------------+      +-----------------------------+
            | Application |      |   BEEP, SSH, SSL, console   |
            |   Protocol  |      |                             |
            +-------------+      +-----------------------------+

My Proposed Layering

                Layer                      Example
            +-------------+      +-----------------------------+
            |   Content   |      |     Configuration data      |
            +-------------+      +-----------------------------+
              |         |
     +-------------+    |
     | Operations  |    |
     +-------------+    \
             |           \
     +-------------+  +--------------+
     |     RPC     |  | Notification |
     +-------------+  +--------------+
              |         /
            +-------------+      +-----------------------------+
            | Application |      |   BEEP, SSH, SSL, console   |
            |   Protocol  |      |                             |
            +-------------+      +-----------------------------+

There is no operation layer in a notification.
There is only transport, notification header, and content.

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

--
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, 24 Jan 2006 10:09:45 -0800

>and I don't think the beep mapping is hindered by this wrapper.

I don't like it at all.
The document is not very clear at all.
There are many details that are buried in
hard-to-read XSD and not explained in
any human-readable text.

>This concept gets somewhat lost.
.
IMO, it is way simpler to explain the notification path
as separate from the operations path.  They are separate
in CLI and SNMP.  I just don't see a notification as a one way
remote procedure call.  It is convoluted.

BTW, we decided awhile back that we didn't want 'void' RPCs.
That is why we have the <ok> element.

>By having two different architectures for these messages, things diverge

Really? What are they?
This looks like a broken architecture to me.
Requests which return responses and/or status
are not handled the same as async. notifications -- which is what
we are chartered to add to netconf.

>4. I don't understand the access control comment.

It was based on <rpc> layering.
It wasn't clear from the document that <notification>
is under <one-way-rpc>.  (Why the extra layer --
oh yeah -- we may add other types of 1-way rpcs
in the future :-)

>another type of asynchronous message, or want to do acknowledged events?

Like what?
We can deal with that problem if it ever comes up.
Extending XML is pretty easy.

>extensibility that this compression might have.

Nobody else seems to want to do this.
(Have the manager listen for <rpc>?)

Why do you want to make this so complicated?
A notification, over RPC, with an operations layer?
What is it used for?  I don't get it.

We should be solving current operational problems.
We have both the syslog and SNMP notification models
in use today.  We should build on that, not reinvent it.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Jan 2006 21:20:39 +0100

> hard-to-read XSD and not explained in

[...]

Andy, I find your comments related to notifications a bit harsh and
not really very constructive. If you think details are missing, please
pose the question and let people have a chance to supply the details
that are not well explained in human readable text. (I note that the
level of detail you provided on this list was also not that great.)

OK, I understand you don't like the proposed <one-way-rpc> framing of
notifications while others seem to think this is a good idea to have.
So lets talk about the pros and cons of introducing <one-way-rpc>.
Once we have a clear cut list of the pros and cons, the WG might come
to an informed conclusion. Right now, I have the feeling that the tone
of the debate is counter productive and upsetting contributors.

Perhaps it helps if Sharon posts an itemized list why having the
<one-way-rpc> framing is a good idea and Andy posts an itemized list
why the addition of <one-way-rpc> is not needed and a really bad idea.
If both manage to stick to clear technical arguments, we might have an
easier way to move forward on this issue.

/js

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 24 Jan 2006 13:26:06 -0800

>of the debate is counter productive and upsetting contributors.

okay.

I will be quiet now and let others read the draft
and make comments.

I have found that there is no better way to improve a design
than by implementing it.  I believe both co-Chairs of this WG
would rather start (any charter item) with a deployed working
solution than with an untested proposal. 

BTW, I will not interpret silence as positive consensus,
so speak up if you have opinions.

>easier way to move forward on this issue.

I don't think we should have a complicated architecture
unless we FULLY UNDERSTAND WHY.
I am never swayed by arguments like "we might
want to do some unknown thing the future".
If the WG agrees on specific future extensions, that's
something else.  All engineering tradeoffs need to be cost-justified.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 24 Jan 2006 22:35:29 +0100 (CET)

Hi,

This has probably been discussed before, and the answer might be
obvious, but I can't find anything in the archives.  I'd like to know
why a new notification framework is needed?  Is it simply that we need
to be able to send larger messages than what syslog can do?  Or is it
because the content of the notifications will be tightly coupled to the
ordinary netconf content, and therefore it's easier to use a new
scheme than trying to map the netconf model to syslog?  Or something
else?

I think the most important question then is the session model - if the
manager should set up the session and keep it open or if the agent
should establish the session when needed.  If the manager is supposed
to keep it open, how well does that scale?  1000 sessions?  10000?

/martin