Subject: RE: notification charter proposal

From: "Glenn Waters" <[email-masked]>
Date: Thu, 17 Nov 2005 17:17:56 -0500

Great news! Good to see a charter proposal for notifications.

Cheers, /gww 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Andy Bierman
> Sent: Wednesday, November 16, 2005 21:27
> To: [email-masked]
> Subject: notification charter proposal
> 
> Hi,
> 
> Please comment on the following charter text before it goes to the
> ADs for approval.
> 
> thanks,
> Andy and Simon
> 
> ============================================================
> 
> NETCONF WG Charter Clarification proposal:
> 
> The original NETCONF WG charter contains the following line item,
> describing the characteristics that the protocol should have:
> 
>    - Provides support for asynchronous notifications
> 
> This support was removed from the protocol for several reasons,
including:
> 
>  - Removal of multiple channels (or connections) per session
>  - Inconsistent notification support capabilities for each application
> mapping
>  - Lack of a configurable notification type selection (filtering)
> mechanism
>  - Lack of consensus on feature importance
>  - Lack of time to reach consensus on all these issues
> 
> Some time has passed, and there is now WG consensus to finish this
> work item, however the single line in the original charter needs to
> be expanded and this work scoped in much more detail.
> 
> The NETCONF Notification work shall consist of the following:
> 
>  - Specify the <hello> message (capability exchange) details to
>     support notifications.
>  - Specify the application mapping details to support notifications.
>  - Specify the protocol syntax and semantics of a notification
message.
>  - Specify a mechanism for controlling the delivery (turn on/off)
>    of notifications during a session.
>  - Specify a mechanism for selectively receiving a configurable subset
> of all
>    possible notification types.
> 
> An individual submission Internet Draft has been proposed to the WG
> as the starting point for this work.  Unless there are any strong
> objections or alternate proposals, the WG shall adopt the document
> identified as 'draft-chisholm-netconf-event-01.txt' as the starting
> point for this work.
> 
> Goals and Milestones
> 
>   Dec 05   Update charter
>   Jan 06   Submit first version of NETCONF Notifications document
>   Sep 06   Begin WGLC of NETCONF Notifications document
>   Dec 06   Submit final version of NETCONF Notifications document to
> IESG for
>            consideration
> 
> 
> 
> 
> --
> 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: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Tue, 22 Nov 2005 11:09:44 +0200

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> For starters, should there be a minimum max-message size in NETCONF?
> If so, what should it be? 1500 bytes? 65535 bytes? More?  I 
> wonder if there is any consensus on this very specific detail.
> 
> 

Is this a notification (or event message) related question, or a generic
NETCONF issue?

FWIW, if the 1500 bytes figure is related in anyway with the approximate
max length of a Ethernet package payload, the IEEE 802.3 WG is extending
this value to 2k, so we would like to align with this new standard value
rather than falling into a backwards compatibility CLR. 

Regards,

Dan

---

From: "Glenn Waters" <[email-masked]>
Date: Tue, 22 Nov 2005 09:59:08 -0500

> Note: I am not against a) nor am I against b) and c) - it is just
> important for me that once we talk about adding notifications, we
> better be clear what their semantics are and which role they can play
> in a systems view.

Absolutely agree. Let's continue the discussion. At this point I too am
not against (a), (b), or (c) and understanding notifications role is
critical.
 
> /js

Regards, /gww

---

From: "Glenn Waters" <[email-masked]>
Date: Tue, 22 Nov 2005 13:54:47 -0500

I view option (b) as being the most similar to SNMPv3 error codes. As I
understood it, option (b) it is trying to indicate protocol level
(error) responses. Option (c) is trying to indicate data level
(semantic) responses.

Regards, /gww 

On
> Behalf Of David B Harrington
> Sent: Tuesday, November 22, 2005 11:17
> To: 'Phil Shafer'; [email-masked]
> Cc: Chisholm, Sharon [CAR:5K50:EXCH]; [email-masked]
> Subject: RE: notification charter proposal
> 
> Hi Phil,
> 
> My impression is that option c) is similar to error codes in an SNMPv3
> Response message that explains the problem, so the sender can try to
> correct the problem, such as by shortening a TooBig message by
> removing the largest varbind. I agree there are limited cases where a
> non-intelligent notification sender could auto-correct the semantics,
> and the TooBig issue could be handled via capabilities.
> 
> One response might be to NOT resend, and to not send future
> notifications of a specific type, if the sender is made aware that
> specific notifications can not be handled due to a semantics problem.
> 
> Another response might be to drop back to a different version or
> different protocol to get a message through. Some SNMP-based NMSs drop
> back to lesser  versions and protocols when the default stops working,
> such as dropping from SNMPv3 to SNMPv1 to ping.
> 
> It might also be useful if another notification was generated, either
> in netconf or syslog or snmp, that alerted the administrator that
> there is an interoperability problem related to a specific
> notification from managed device A to management application B.
> 
> Dbh
> 
> > [mailto:[email-masked]] On Behalf Of Phil Shafer
> > Sent: Tuesday, November 22, 2005 10:42 AM
> > To: [email-masked]
> > Cc: Sharon Chisholm; [email-masked]
> > Subject: Re: notification charter proposal
> >
> > Juergen Schoenwaelder writes:
> > >c) The notification sender sends a notification and gets a
> > confirmation
> > >   that an entity dealing with notifications actually understood
> the
> > >   semantics associated with the notification.
> >
> > Dumb question:  what does one do with a system that supports you
> > option (c)?  If I sent a notification, the receiver tells me my
> > semantics are off, then what happens?  I resend?  I resend to
> another
> > target?  I auto-correct my semantics?  Are there realistic options
> > that I have as a non-intelligent notification sender?
> >
> > Thanks,
> >  Phil
> >
> > --

---

From: "Hector Trevino \(htrevino\)" <[email-masked]>
Date: Wed, 23 Nov 2005 09:12:14 -0800

Back from vacation and just catching up on these discussions...

I think that option "a" is sufficient, however, option "b" could also be
included for those users that feel application level confirmations/acks
are needed. 

Hector

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Juergen Schoenwaelder
Sent: Wednesday, November 23, 2005 9:20 AM
To: Phil Shafer
Cc: Sharon Chisholm; [email-masked]
Subject: Re: notification charter proposal

confirmation
> >   that an entity dealing with notifications actually understood the
> semantics are off, then what happens?  I resend?  I resend to another 

If you talk to a person, you can get back either

a) nothing
b) "I heard you"
c) "I understood what you were saying"

It of course depends on the smartness of the whole system how you react.
Some humans are fine when they achieve b), some other implementations
feel better if they know they have achieved c).

Sure, implementation complexity goes up from a) to c) and the added
value of c) might not be worth the extra effort it causes. So perhaps
the decision is between a) and b).

/js

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

--
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: "Glenn Waters" <[email-masked]>
Date: Wed, 23 Nov 2005 21:42:20 -0500

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 

> From: Andy Bierman [mailto:[email-masked]]
> 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];
> [email-masked]
> 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
> 
>

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 24 Nov 2005 20:19:29 -0500

hi

No, they are not the same, but the transport layer one seems to be
sufficient from what I have seen. I suggest we don't do anything to
preclude the later addition of an application level acknowledgements,
but that we don't provide one now. The design in the current draft does
this.

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of McDonald, Ira
Sent: Thursday, November 24, 2005 3:58 PM
To: [email-masked]
Subject: RE: notification charter proposal

Hi,

As Juergen Schoenwaelder just pointed out - a transport layer ACK does
NOT have the same semantics as an upper layer ACK that indicates receipt
of a well-formed XML message.

Confusing the two is not helpful - NetConf is supposed to behave the
same over any transport.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Sharon Chisholm
> Sent: Thursday, November 24, 2005 10:23 AM
> To: [email-masked]
> hi
> The only interest I saw historically in informs were from people who 
> were disappointed we didn't run over TCP. After some investigation, 
> people generally chose other means to maintain confidence that they 
> were not loosing information.  I just didn't see informs used in 
> practice.
> 
> Given we now run over TCP, I have difficulty seeing people using 
> acknowledged notifications in practice. The solution could be defined,

> but I don't really know if there a lot of value in doing so.
> 
> Sharon
> 
> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: Tuesday, November 22, 2005 9:32 AM
> To: Waters, Glenn [CAR:IO47:EXCH]
> On Tue, Nov 22, 2005 at 09:00:20AM -0500, Glenn Waters wrote:
> 
> > > b) The notification sender sends a notification and gets a
> confirmation
> > >    that the notification was understood to the extend
> that it could
> be
> > >    handed over to an entity dealing with notifications. (This is
> what
> > >    SNMP notifications actually do.)
> > 
> > I don't think that there is enough value in sending a
> response in this
> 
> > case since there is little recourse the sender can take to
> correct the
> 
> > issue. There is the possibility the sender could reduce the message
> > size but that can be handled in other ways (such as the receiver 
> > reconfiguring the max size the sender should send). I can't 
> think of
> > what else a sender would possibly do with a response. Maybe
> it would
> > help to identify those items to help decide if a response would be
> > useful.
> 
> Knowledge of the fact that you were not understood can be very useful,

> even if you do not know how to make yourself understood.
> 
> You are arguing from a very narrow protocol centric perspective and
> I agree that from this protocol centric perspective there is hardly
> something you can do. However, if you take a more system wide
> perspective, then I think one can easily make a case for b) 
> and even for
> c).
> 
> PS: There are also strong ties here to notification logging (see the
>     NOTIFICATION-LOG-MIB produced by the DISMAN WG). The information
>     whether a notification was "understood" can actually be used to
>     decide what remains in a log and what can be purged. Without such
>     information, the notification originator actually has to log 
>     everything (and maybe rely on the receiver to clear log entries).
> 
> --

---

From: Rathnakumar Kayyar <[email-masked]>
Date: Fri, 25 Nov 2005 09:37:17 +0530

A note on the application.

CMISE/CMIP/GDMO's  "confirmed notification" provides the means of sending a
confirmation from the application level. Though it is the application's
responsibility to confirm, the protocol and the
data model provide the support. Usage wise, I have seen mobile switches
re-sending the CDR via
a CMIP notification, re-attempting if the ACK doesn't come, and finally
logging it to the local
disk, to be retrieved later via tftp by the billing application.

Rathnakumar Kayyar

[Disclaimer: I joined the group yesterday, so igonre this if this is beyond
the scope of the 
discussion -:) 

-----Original Message-----
From: Sharon Chisholm [mailto:[email-masked]]
Sent: Friday, November 25, 2005 6:49 AM
To: [email-masked]
Subject: RE: notification charter proposal

hi

Sharon

-----Original Message-----
Behalf Of McDonald, Ira

Hi,

Cheers,
- Ira

---

From: "Hector Trevino \(htrevino\)" <[email-masked]>
Date: Mon, 28 Nov 2005 08:49:53 -0800

Comments in-line (HT)
Hector

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eliot Lear
Sent: Thursday, November 24, 2005 12:59 AM
To: Andy Bierman
Cc: Glenn Waters; [email-masked]; Phil Shafer; Sharon
Chisholm; [email-masked]
Subject: Re: notification charter proposal

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..).

> I would like to make sure the mandatory transport (SSH) 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.

HT: Same here & Appendix D was put in as an attempt to address this
issue

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

HT: We are trying to do a combination of the two above. There are some
good things about syslog which could/should be preserved but as I think
everyone agrees, syslog has limitations and there is no reason why a
second approach as you call it can't be pursued. More specifically to
your first point, the appendix in the doc does not discuss how to
maintain structured data definitions in sync but we have looked at this
issue. The latest syslog-protocol draft only has 2-3 definitions thus
far. 

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: "Hector Trevino \(htrevino\)" <[email-masked]>
Date: Mon, 28 Nov 2005 12:56:54 -0800

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, November 28, 2005 1:09 PM
To: Hector Trevino (htrevino)
Cc: Sharon Chisholm; [email-masked]
Subject: Re: notification charter proposal

Hector Trevino (htrevino) wrote:

>Agree and as I said in a previous e-mail... a transport layer (TCP) ACK

>is sufficient for most applications. An application layer ACK could be 
>included in the spec for those users who think they need it. I suggest 
>that this should be separate of app layer protocol (e.g. BEEP) built-in

>acks.

Do you mean an optional-to-implement ACK feature?
Or optional-to-use ACK feature?

HT:  I meant an optional-to-use ACK feature. However, thus far
notifications are optional (another capability).   

What is this mechanism exactly?
Don't care because you mean optional-to-implement and don't plan on
implementing it?

HT: No, we haven't discussed the mechanism because the current document
proposes NO appl layer ACKs. Some people want to have appl layer ACKs.
If there is enough support and justification for this additional
functionality then we could specify it. 

Nobody has specified the messages, timeouts, state machine, etc.
It's more complicated than "throw in an ACK".   IMO it is
bad engineering to build this complexity into the protocol if it's not
important enough to be mandatory to implement.

HT: Sure, agree.  

Please see my previous email on the <notify-confirm> RPC idea.
I don't see why we would spend a lot of effort on a complicated
optional-to-implement solution when we already have a mandatory solution
available. 

The <notify-confirm> RPC and setting the ack-required flag in the
<notify> message could be optional to implement or support.
But this is just another RPC, and there is no need to define a
complicated architecture because RPC is already defined.

BTW, this provides a 3-way confirm, not 2-way like an application ACK. 
Since the agent replies <ok> to the <notify-confirm> RPC request, the
manager knows that the agent got the application ACK.

HT: I saw that and it is certainly a possibility. The current doc
introduces rpc-one-way (for unackd notifications). You could use the
existing rpc-request, rpc-reply for ackd notifications. I guess
depending on where the ack has to be originated what you're proposing
may be better but at an extra ACK expense.  

Andy

>Sent: Thursday, November 24, 2005 6:19 PM
>To: [email-masked]

>NOT have the same semantics as an upper layer ACK that indicates 
>receipt of a well-formed XML message.
>
>Ira McDonald (Musician / Software Architect) Blue Roof Music / High 
>North Inc PO Box 221  Grand Marais, MI  49839
>phone: +1-906-494-2434
>>You are arguing from a very narrow protocol centric perspective and I 
>>agree that from this protocol centric perspective there is hardly 
>>perspective, then I think one can easily make a case for b) and even 
>>for c).
>>