Subject: [Netconf] FW: I-D Action:draft-chisholm-netconf-not-content-00.txt

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 7 Jul 2008 17:09:28 -0400

Hi

The following draft defines standard content for NETCONF Notifications,
with an aim to support full-lifecycle configuration management. This
work was deferred from the original NETCONF Notification protocol work
because of the separation of protocol and content and was brought up at
the mike (by someone other then the authors) at the last IETF meeting as
a gap in our NETCONF solution.

We would like to discuss this work at the upcoming meeting in Dublin.

Sharon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, July 07, 2008 5:00 PM
To: [email-masked]
Subject: I-D Action:draft-chisholm-netconf-not-content-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : NETCONF Notification Content
	Author(s)       : S. Chisholm, et al.
	Filename        : draft-chisholm-netconf-not-content-00.txt
	Pages           : 29
	Date            : 2008-07-07

The NETCONF Event Notifications standard specifies the mechanism by
which NETCONF clients can subscribe to and receive event notifications.
However, with the exception of a timestamp, no standard Notification
content was defined.  This memo defines a set of information that shouFrom [email-masked]  Mon Jul  7 14:09:44 2008
Content-class: urn:content-classes:message
Date: Mon, 7 Jul 2008 17:09:28 -0400
From: "Sharon Chisholm" <[email-masked]>
To: <[email-masked]>
Subject: [Netconf] FW: I-D Action:draft-chisholm-netconf-not-content-00.txt
Sender: [email-masked]

This is a multi-part message in MIME format.
Hi

The following draft defines standard content for NETCONF Notifications,
with an aim to support full-lifecycle configuration management. This
work was deferred from the original NETCONF Notification protocol work
because of the separation of protocol and content and was brought up at
the mike (by someone other then the authors) at the last IETF meeting as
a gap in our NETCONF solution.

We would like to discuss this work at the upcoming meeting in Dublin.

Sharon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, July 07, 2008 5:00 PM
To: [email-masked]
Subject: I-D Action:draft-chisholm-netconf-not-content-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : NETCONF Notification Content
	Author(s)       : S. Chisholm, et al.
	Filename        : draft-chisholm-netconf-not-content-00.txt
	Pages           : 29
	Date            : 2008-07-07

The NETCONF Event Notifications standard specifies the mechanism by
which NETCONF clients can subscribe to and receive event notifications.
However, with the exception of a timestamp, no standard Notification
content was defined.  This memo defines a set of information thald
be included in all NETCONF notifications, information that should be
included based on class of notification and also defines a set of
specific notifications to support specific management functions, such as
configuration.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chisholm-netconf-not-content-0
0.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 25 Jul 2008 09:27:53 -0400

Hi

I don't know if I'm suppose to use up a lot of bandwidth on the mailing
list to discuss things that are not yet part of the charter, but I
wanted to make a make a few comments about Data Change Notifications
(configuration changes) prior to the meeting.

It needs to be clarified that configuration change notifications get
sent out for changes to the running configuration. This potentially
means that a bunch of edit-config operations are applied on a candidate
configuration to create this change. I suspect this means we need to
send multiple change events. I had based the description originally on
an implementation that only edited running configuration so I missed
this.

An open issue is how to ensure that you didn't miss a configuration
change event due to throttling. The traditional use of sequence numbers
to aid detection of this doesn't work with filtering. Assigning a
version number to the entire configuration might be a more effective
method. This is easy with a centralized configuration store, but if the
configuration is distributed throughout the network element, I don't
know how hard this is.

Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Chisholm, Sharon (CAR:ZZ00)
Sent: Monday, July 07, 2From [email-masked]  Fri Jul 25 06:28:18 2008
Content-class: urn:content-classes:message
Date: Fri, 25 Jul 2008 09:27:53 -0400
From: "Sharon Chisholm" <[email-masked]>
To: <[email-masked]>
Subject: Re: [Netconf] FW: I-D
	Action:draft-chisholm-netconf-not-content-00.txt
Sender: [email-masked]

Hi

I don't know if I'm suppose to use up a lot of bandwidth on the mailing
list to discuss things that are not yet part of the charter, but I
wanted to make a make a few comments about Data Change Notifications
(configuration changes) prior to the meeting.

It needs to be clarified that configuration change notifications get
sent out for changes to the running configuration. This potentially
means that a bunch of edit-config operations are applied on a candidate
configuration to create this change. I suspect this means we need to
send multiple change events. I had based the description originally on
an implementation that only edited running configuration so I missed
this.

An open issue is how to ensure that you didn't miss a configuration
change event due to throttling. The traditional use of sequence numbers
to aid detection of this doesn't work with filtering. Assigning a
version number to the entire configuration might be a more effective
method. This is easy with a centralized configuration store, but if the
configuration is distributed throughout the network element, I don't
know how hard this is.

Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Chisholm, Sharon (CAR:ZZ00)
Sent: Monday, July008 5:09 PM
To: [email-masked]
Subject: [Netconf] FW: I-D
Action:draft-chisholm-netconf-not-content-00.txt

Hi

Sharon

-----Original Message-----

content was defined.  This memo defines a set of information that should

 07, 2008 5:09 PM
To: [email-masked]
Subject: [Netconf] FW: I-D
Action:draft-chisholm-netconf-not-content-00.txt

Hi

Sharon

-----Original Message-----

content was defined.  This memo defines a set of information that should

---

From: "Kent Watsen" <[email-masked]>
Date: Mon, 28 Jul 2008 15:27:45 -0700

We haven't been able to find a reason to notify an app when a candidate
datastore is modified - we only send out notifications for running and
startup datastores.   Of course, our notifications indicate which
datastore was modified and so an app can filter the notification-stream
to receive just the config-change events for the datastore(s) of
interest.  So, if the WG supports notifications for candidate
datastores, apps can still filter them out.

Regarding missing a configuration change event due to throttling - why
does this matter?  That is, are you supporting an auditing use-case
whereby each event must be captured? - what happens if the device has
purged the log before your app had a chance to re-fetch it?  For us,
simply kFrom [email-masked]  Mon Jul 28 15:28:18 2008
Content-class: urn:content-classes:message
Date: Mon, 28 Jul 2008 15:27:45 -0700
From: "Kent Watsen" <[email-masked]>
To: "Sharon Chisholm" <[email-masked]>,
	<[email-masked]>
Subject: Re: [Netconf] FW:
	I-DAction:draft-chisholm-netconf-not-content-00.txt
Sender: [email-masked]

We haven't been able to find a reason to notify an app when a candidate
datastore is modified - we only send out notifications for running and
startup datastores.   Of course, our notifications indicate which
datastore was modified and so an app can filter the notification-stream
to receive just the config-change events for the datastore(s) of
interest.  So, if the WG supports notifications for candidate
datastores, apps can still filter them out.

Regarding missing a configuration change event due to throttling - why
does this matter?  That is, are you supporting an auditing use-case
whereby each event must be captured? - what happens if the device has
purged the log before your app had a chance to re-fetch it?  For us,
sinowing that the configuration changed is what is most important
- we plan to use fingerprints to track config-changes...

BTW, note that some devices may support more than one candidate
datastore and hence the notification would need to indicate the specific
one (not just a const datastore-identifier like "candidate")

Thanks,
Kent

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Sharon Chisholm
> Sent: Friday, July 25, 2008 9:28 AM
> To: [email-masked]
> Subject: Re: [Netconf] FW:
I-DAction:draft-chisholm-netconf-not-content-
> 00.txt
> Sent: Monday, July 07, 2008 5:09 PM
> To: [email-masked]
> ________________________________________mply knowing that the configuration changed is what is most important
- we plan to use fingerprints to track config-changes...

BTW, note that some devices may support more than one candidate
datastore and hence the notification would need to indicate the specific
one (not just a const datastore-identifier like "candidate")

Thanks,
Kent

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Sharon Chisholm
> Sent: Friday, July 25, 2008 9:28 AM
> To: [email-masked]
> Subject: Re: [Netconf] FW:
I-DAction:draft-chisholm-netconf-not-content-
> 00.txt
> Sent: Monday, July 07, 2008 5:09 PM
> To: [email-masked]
> _________________________________________
> Netconf mailing list
> [email-masked]

_____________

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 29 Jul 2008 11:10:28 -0400

Hi

The use case around throttling is that a configuration change has
occurred but due to NE overload the configuration change notification
gets dropped on the floor at some point, potentially before reaching the
NETCONF server. If you are running a configuration application that
replicates the NE's configuration for scalability or some other reason,
you will now have a stale copy of the configuration, but may not know
it.

Sharon

-----Original Message-----
From: Kent Watsen [mailto:[email-masked]] 
Sent: Monday, July 28, 2008 6:28 PM
To: Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: RE: [Netconf] FW:

We haven't been able to find a reason to notify an app when a candidate
datastore is modified - we only send out notifications for running and
startup datastores.   Of course, our notifications indicate which
datastore was modified and so an app can filter the notification-stream
to receive just the config-change events for the datastore(s) of
interest.  So, if the WG supports notifications for candidate
datastores, apps can still filter them ouFrom [email-masked]  Tue Jul 29 08:10:30 2008
Content-class: urn:content-classes:message
Date: Tue, 29 Jul 2008 11:10:28 -0400
From: "Sharon Chisholm" <[email-masked]>
To: "Kent Watsen" <[email-masked]>, <[email-masked]>
Subject: Re: [Netconf] FW:
	I-DAction:draft-chisholm-netconf-not-content-00.txt
Sender: [email-masked]

Hi

The use case around throttling is that a configuration change has
occurred but due to NE overload the configuration change notification
gets dropped on the floor at some point, potentially before reaching the
NETCONF server. If you are running a configuration application that
replicates the NE's configuration for scalability or some other reason,
you will now have a stale copy of the configuration, but may not know
it.

Sharon

-----Original Message-----
From: Kent Watsen [mailto:[email-masked]] 
Sent: Monday, July 28, 2008 6:28 PM
To: Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: RE: [Netconf] FW:

Ret.

simply knowing that the configuration changed is what is most important

Thanks,
Kent

Behalf

> A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chisholm-netconf-not-contegarding missing a configuration change event due to throttling - why
does this matter?  That is, are you supporting an auditing use-case
whereby each event must be captured? - what happens if the device has
purged the log before your app had a chance to re-fetch it?  For us,
simply knowing that the configuration changed is what is most important
- we plan to use fingerprints to track config-changes...

Thanks,
Kent

Behalf

>nt-0

 0.txt

---

From: "Kent Watsen" <[email-masked]>
Date: Wed, 30 Jul 2008 13:54:21 -0700

Sorry, I meant, why does it matter to know the sequence-number of the
missed logs?  - is your intent for the application to use the
sequence-number to re-fetch the log that was throttled?  If not, then
maybe a fingerprint would be better?

Thanks,
Kent

> From: Sharon Chisholm [mailto:[email-masked]]
> Sent: Tuesday, July 29, 2008 11:10 AM
> To: Kent Watsen; [email-masked]
> occurred but due From [email-masked]  Wed Jul 30 13:54:14 2008
Date: Wed, 30 Jul 2008 13:54:21 -0700

Sorry, I meant, why does it matter to know the sequence-number of the
missed logs?  - is your intent for the application to use the
sequence-number to re-fetch the log that was throttled?  If not, then
maybe a fingerprint would be better?

Thanks,
Kent

> From: Sharon Chisholm [mailto:[email-masked]]
> Sent: Tuesday, July 29, 2008 11:10 AM
> To: Kent Watsen; [email-masked]
> occurred buto NE overload the configuration change notification
> > the mike (by someone other then the authors) at the last IETF
meeting
> as
> > specific notifications to support specific management functions,
such
> as

t due to NE overload the configuration change notification
> > the mike (by someone other then the authors) at the last IETF
meeting
> as
> > specific notifications to support specific management functions,
such
> as

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 31 Jul 2008 00:03:24 +0100 (IST)

> one (not just a const datastore-identifier like "candidate")

If a device supports more than one candidate, then that's an extension
to NETCONF.  rfc4741 specifies that there is one candidate, and it is
refered to as <candidate/> in the operations.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 31 Jul 2008 00:03:24 +0100 (IST)

/martin