RE: notification charter proposal

["Glenn Waters" <gww@nortel.com>]

Andy, I think you may have taken my comments a little out of context.
Regardless I absolutely agree with you that the feature set at the
protocol level must be the same no matter what the transport protocol
is. Sorry if I wasn't clear.

With respect to the ACK discussion there is something to be said for
consistency. That said I would still like to understand what the
possible value is of the (b) option.

Question about ACK (assuming we do them) -- do people envision that if
we ACK notifications then (1) are the notifications are serialized,
i.e.: send notify, wait for ACK, send notify, wait for ACK, etc.; or,
(2) are the notifications in parallel, i.e.: send some number of
notifications and process the ACKs as they come in.

I think (2) but wanted to clarify.

Regards, /gww 

> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com]
> Sent: Wednesday, November 23, 2005 21:15
> To: Eliot Lear
> Cc: Waters, Glenn [CAR:IO47:EXCH]; McDonald, Ira; j.schoenwaelder@iu-
> bremen.de; Phil Shafer; Chisholm, Sharon [CAR:5K50:EXCH];
> netconf@ops.ietf.org
> Subject: Re: notification charter proposal
> 
> Eliot Lear wrote:
> 
> >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.
> >
> >
> 
> 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
> 
> 


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