Subject: RE: NETCONF Notifications: Consensus Points

From: "Andrea Westerinen \(andreaw\)" <[email-masked]>
Date: Sun, 27 Nov 2005 10:05:47 -0800

Randy, Don't hold back :-).

I agree that in a high-delay environment that this would not be ideal -
however, in a secure environment where you want to limit notifications
or in a high-traffic/high-use environment, then it might make sense.
Also, I did not indicate whether this was a synchronized ACK or ACKs
could be batched or what the timing requirements were - just that this
was one use by the sender of an ACK from the receiver.

Andrea  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Saturday, November 26, 2005 10:21 PM
> To: [email-masked]
> Subject: Re: NETCONF Notifications: Consensus Points
> 
> Hi -
> 
> > From: "Andrea Westerinen (andreaw)" <[email-masked]>
> > To: "Randy Presuhn" <[email-masked]>; 
> > <[email-masked]>
> > Sent: Saturday, November 26, 2005 9:42 PM
> > Subject: RE: NETCONF Notifications: Consensus Points
> >
> 
> > One usage of application-level ACKs (by the sender) is to disable 
> > sending notifications/event messages until specifically re-enabled.
> ...
> 
> That depends on how one structures the protocol.  My initial 
> reaction to
> such a proposed usage is, in admittedly non-technical terms, 
> "Eww, gross!"
> More to the point, if the protocol only permits a single notification
> "in the pipe" at a time, it would be unsuitable for use in 
> high-delay (think NASA)
> environments.   Perhaps we can live with that; I don't know 
> whether anyone
> would use netconf in high-delay environments.
> 
> This is not a necessary property of application-level 
> acknowledgements;
> an example of a protocol that does not have this property is CMIP.
> 
> Randy
> 
> 
> --
> 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: "Hector Trevino \(htrevino\)" <[email-masked]>
Date: Tue, 29 Nov 2005 09:18:46 -0800

The last appendix in the netconf-event doc has a list of proposed syslog
fields which could be re-used. The syslog-draft has only 3 SD-IDs
defined thus far. Left them out of the write-up for now since there
needs to be some description of how these fields are adopted for use and
how they are maintained in sync w/the syslog work. Also, is the reverse
true (i.e. if the equivalent of SD-IDs are defined for NETCONF are they
then introduced into syslog?). We have looked at some of this at Cisco
and it seems to be a good idea (SD-ID equivalence) but haven't worked
out all the details. 

Hector

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Andy Bierman
Sent: Tuesday, November 29, 2005 9:42 AM
To: Sharon Chisholm
Cc: [email-masked]
Subject: Re: NETCONF Notifications: Consensus Points

Sharon Chisholm wrote:

><Andy>
>Notification Info Model/Payload
>
>  There is WG consensus to reuse syslog classification, although
>  the ability to transfer additional user data (similar to the OBJECTS
>  clause in an SNMP notification) is also required.  The option
>  of asking the SYSLOG WG for enhancements to RFC 3195 is also
>  possible, and some WG members prefer this approach if syslog
>  is going to be enhanced in any meaningful way.
></Andy>
>
>This one I think requires more discussion before we can declare some 
>consensus. I think there is a general sense that there is something 
>from the land of syslog that we want to take advantage of and learn 
>from, but I have not seen strong consensus as to what that is. And 
>which version of syslog are people looking to leverage?
>
>I think being able to tunnel syslog content into netconf is good for 
>transitioning and our internet draft discusses this a bit in one of the

>appendices. What is more interesting though, is some of the SD-Params 
>we have developed in syslog. I think bringing these in, not using 
>SD-Param grammar, but as properly tagged XML would be very very useful.
>
>  
>

I think this WG is a little better at discussing detailed text than
abstract concepts.  I suppose we will know which fields people agree on
when we get down in the details and hammer out every option of every
feature from top to bottom and back again.

So go ahead and write up details for SD-Params if you want.
At this point there isn't WG consensus for any particular field of any
message over any transport. 

However several people have expressed concern over reinventing syslog or
SNMP Notifications, and this will be a factor in the process.

>Sharon

Andy

>--
>to unsubscribe send a message to [email-masked] with the 
>word 'unsubscribe' in a single line as the message text body.

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