Subject: RE: notification charter proposal

From: "Glenn Waters" <[email-masked]>
Date: Wed, 23 Nov 2005 13:47:37 -0500

Elliot wrote:

> How about "The right tool for the right job?"  For those who need this
> sort of thing, use BEEP.

I'm not sure how to interpret your comment. If we decide (b) then we
need to support acks in the notification protocol since ssh is the
mandatory to implement transport.

Cheers, /gww  

--
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: Eliot Lear <[email-masked]>
Date: Wed, 23 Nov 2005 20:13:21 +0100

Glenn,

What I'm saying is that while it is true that SSH is the "mandatory to
implement", you only need to have application-level ACKs in the
notification component if THEY are mandatory to implement.  Otherwise
you can leave it to the BEEP mapping and be done with it.

Eliot

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Nov 2005 21:25:06 +0100

> you can leave it to the BEEP mapping and be done with it.

Again,

lets first decide which semantics we need and then talk about the
implementation. I personally have bad feelings if sematics associated
with a netconf protocol operation are determined by the underlying
transport.

/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: Wed, 23 Nov 2005 18:14:31 -0800

>you can leave it to the BEEP mapping and be done with it.

I agree with Juergen on this one.
I would like to make sure the mandatory transport (SSH)
can be used for all the notification features defined.
For the same reason, I don't think Rob's proposal to just
use Syslog over BEEP will work.  These ideas were floated
around before SSH was picked instead of BEEP as expected
at the time.  However, I strongly agree with Rob wrt/
not inventing new info models but rather using the
existing syslog info model to the greatest degree possible.

The feature set at the protocol level should be the same.
The transport implementation of that feature does not have
to be the same of course.

The thread on app-level ACKs is interesting, but keep in mind...
If you make it complicated enough, then it ends up looking
remarkably similar to our <rpc> and <rpc-reply>, except
in the other direction.  (E.g. the agent issues an <rpc>
that says "here take this", and the manager send a <rpc-reply>
that says <ok> or <rpc-error>(too-big | did-not-grok, etc.)

>Eliot

Andy

---

From: Eliot Lear <[email-masked]>
Date: Thu, 24 Nov 2005 08:59:09 +0100

Andy,

I hope you're enjoying some decent Bird today in America and don't
actually read this till later ;-)  Please see below.

> I agree with Juergen on this one.

I agree in part.  I do not want the tail to wag the dog.  Just because
SSH or BEEP does or doesn't have a feature shouldn't dictate the
approach to notifications (events, whatever..).

> can be used for all the notification features defined.

First, if the notification feature is not mandatory, you're probably
adding extra unwanted hair.  But if we go this route, let's make proper
use of mapping mechanisms.  If SSH needs to add an ACK that's already
there for BEEP, don't make BEEP have a 2nd unnecessary ACK.

Now putting the horse before the cart, I think we have a few problems in
this space.  First of all, there is the SYSLOG working group that is
currently attempting to finalize a new specification that will include
some amount of structured data.  We must not simply duplicate their work
in an incompatible way, and so I agree with you there.

However, SYSLOG isn't much more than PRI+Date+host+text.  There's a lot
of room to do better than that.  I think Sharon and crew should be
thinking about one of two directions:

 - what to do with the structured text component contemplated by
   SYSLOG wg (and now's the time to talk to them - and I mean right
   now)

 - creating a second approach that is richer than what SYSLOG has.
   The good here is that event systems have been out there for a
   while, and so perhaps the time is ripe.  The bad is that many
   have tried...

So I don't know which approach is correct.

Finally, I reiterate that events and notifications appear to be
architecturally severable, and so I would like to understand why it is
necessary for the netconf protocol to be extended beyond perhaps a
capability referencing other work.

Eliot

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Nov 2005 09:25:15 +0100

> there for BEEP, don't make BEEP have a 2nd unnecessary ACK.

I guess the BEEP ACK acknowledges the BEEP message and does not ack
that the netconf message was actually well formed and something that
could be handed over to a netconf notification consumer. This might
sound like splitting hairs - but I generally believe that a transport
level ack is not the same as a netconf level ack, unless the transport
actually implements something like c).

Since you know BEEP much better than I do, you can probably point me
to the section where the BEEP spec says it actually does have the ack
semantics we are talking about here (ie, the ack acknowledges the
upper layer correctness of the received BEEP message).

/js

---

From: Eliot Lear <[email-masked]>
Date: Thu, 24 Nov 2005 10:52:44 +0100

If an implementation wants this sort of behavior limit a single
notification to a single MSG and expect a single RPY in response.

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 25 Nov 2005 09:33:31 +0100

Let us keep netconf truly transport independent as the choice of transport protocol can 
also be dictated by other reasons:
- market acceptance
- available toolkits
Balazs