Subject: [Netconf] Are capabilities static or dynamic ?

From: Balazs Lengyel <[email-masked]>
Date: Tue, 28 Oct 2008 22:48:17 +0100

Hello.
A netconf agent will report it's capabilities at the start of the session. But can these 
capabilites change later during the session? I see three use case where they might:
1) A new YANG Module (YAM) is added during run-time. This can be the result of e.g. adding a 
new license key to the node.
2) A capability might be configurable, the superuser might allow or disallow the usage of 
partial-locking or the validate capability
3) A Netconf session survives an upgrade (happens in telecom grade nodes for other OAM sessions)

We could say that the capabilities change only at the end of the session, but if we have an 
ongoing session, that delays the capability change and a new session, that uses the new 
capabilities, that can really lead to confusion. Also maintaining a separate capability set for 
ongoing sessions is a hassle.

On solution could be to allow capability changes and send a Netconf notification about them.

Opinions?

Balazs
_____________________________From [email-masked]  Tue Oct 28 14:48:24 2008
Date: Tue, 28 Oct 2008 22:48:17 +0100
From: Balazs Lengyel <[email-masked]>
To: netconf mailing list <[email-masked]>
Subject: [Netconf] Are capabilities static or dynamic ?
Sender: [email-masked]

Hello.
A netconf agent will report it's capabilities at the start of the session. But can these 
capabilites change later during the session? I see three use case where they might:
1) A new YANG Module (YAM) is added during run-time. This can be the result of e.g. adding a 
new license key to the node.
2) A capability might be configurable, the superuser might allow or disallow the usage of 
partial-locking or the validate capability
3) A Netconf session survives an upgrade (happens in telecom grade nodes for other OAM sessions)

We could say that the capabilities change only at the end of the session, but if we have an 
ongoing session, that delays the capability change and a new session, that uses the new 
capabilities, that can really lead to confusion. Also maintaining a separate capability set for 
ongoing sessions is a hassle.

On solution could be to allow capability changes and send a Netconf notification about them.

Opinions?

Balazs
_____________________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

____________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 29 Oct 2008 04:54:24 +0100

> On solution could be to allow capability changes and send a Netconf

Does the notification just communicate the capability-change-event and
the manager then has to grab new capabilites from the NETCONF
monitoring data model or is the idea that the capability-change-event
carries all capabilities (or a delta of the capabilities)?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 29 Oct 2008 04:54:24 +0100

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 29 Oct 2008 10:28:56 +0100

Hello,
IMHO the notification should carry the full list of capabilities. If someone is interested 
(subscribed) why should we force him to issue a get? However a notification without much 
content is usable as well.

Sharon could include this in her draft.

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 29 Oct 2008 10:28:56 +0100

Hello,

Balazs

---

From: "Mark Scott" <[email-masked]>
Date: Thu, 30 Oct 2008 11:14:50 -0400

Hi Balazs,

I am in favour of allowing dynamic capabilities changes.  This was a
base assumption in including them in the NETCONF monitoring data model.

I am also in favour of two levels of notification.  Not only for this
but for notifications in general.

We consider these 'light-weight' (terse) and 'heavy-weight' (detailed)
notifications.  The former simply indicates a particular instance has
been modified and managers decide whether or not to do anything (eg:
'capabilities datamodel: update').  The latter actually sends the delta
of the change in the notification (eg: 'capabilities datamodel:  Y
added').  

Individual managers determine which notification type (level of detail)
they want by subscription.

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Balazs Lengyel
Sent: Wednesday, October 29, 2008 5:29 AM
To: Balazs Lengyel; netconf mailing list
Subject: Re: [Netconf] Are capabilities static or dynamic ?

Hello,
IMHO the notification should carry the full list of capabilities. If
someone is interested
(subscribed) why should we force him to issue a get? However a
notification without much content is usable as well.

Balazs

Juergen Schoenwaelder wrote:
> On Tue, Oct 2From [email-masked]  Thu Oct 30 08:15:08 2008
Content-class: urn:content-classes:message
Date: Thu, 30 Oct 2008 11:14:50 -0400
From: "Mark Scott" <[email-masked]>
To: "Balazs Lengyel" <[email-masked]>,
	"netconf mailing list" <[email-masked]>
Subject: Re: [Netconf] Are capabilities static or dynamic ?
Sender: [email-masked]

Hi Balazs,

I am in favour of allowing dynamic capabilities changes.  This was a
base assumption in including them in the NETCONF monitoring data model.

I am also in favour of two levels of notification.  Not only for this
but for notifications in general.

We consider these 'light-weight' (terse) and 'heavy-weight' (detailed)
notifications.  The former simply indicates a particular instance has
been modified and managers decide whether or not to do anything (eg:
'capabilities datamodel: update').  The latter actually sends the delta
of the change in the notification (eg: 'capabilities datamodel:  Y
added').  

Individual managers determine which notification type (level of detail)
they want by subscription.

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Balazs Lengyel
Sent: Wednesday, October 29, 2008 5:29 AM
To: Balazs Lengyel; netconf mailing list
Subject: Re: [Netconf] Are capabilities static or dynamic ?

Hello,
IMHO the notification should carry the full list of capabilities. If
someone is interested
(subscribed) why should we force him to issue a get? However a
notification without much content is usable as well.

Balazs

Juergen Schoenwaelder wrote:
> On Tue,8, 2008 at 10:48:17PM +0100, Balazs Lengyel wrote:
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 30 Oct 2008 09:28:52 -0700

> but for notifications in general.

I support any excuse to define some standard NETCONF content.
However, it would break the contract of any existing sessions
to take away or modify any capabilities each existing
session already knows about.  Adding new capabilities
mid-session is OK, but nothing else.  (Operationally, a way
to override that rule is probably needed.)

> of the change in the notification (eg: 'capabilities datamodel:  Y

The subscription already has filters, so the notification
content needs to be easily filtered, which means more
general fields than eventTime (like eventClass, eventSubClass,
and eventSeverity?)

I don't think "terse vs. detailed" is a good general filter though.
(eventDetailLevel?)

But you are describing an extension to the <create-subscription>
parameters, right?  Or do you mean the agent will generate
two notifications for each event (terse and detailed) and
applications will know to filter one of them out?

> they want by subscription.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 30 Oct 2008 09:28:52 -0700

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 30 Oct 2008 20:34:03 -0400

>to override that rule is probably needed.)

Sure, it's painful, but when a user removes a software module or a
license key, the abilities of the device will change.  It's
unavoidable.  The options are (a) announce it, or (b) nuke any
previous client sessions.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Thu, 30 Oct 2008 20:34:03 -0400

Thanks,
 Phil

---

From: "Mark Scott" <[email-masked]>
Date: Thu, 30 Oct 2008 21:30:50 -0400

I would prefer to announce it rather than kill the sessions.

Well behaved clients keep their sessions.  Others can expect errors if
they try to use the capability once it's been revoked.

mark

-----Original Message-----
From: Phil Shafer [mailto:[email-masked]] 
Sent: Thursday, October 30, 2008 8:34 PM
To: Andy Bierman
Cc: Scott, Mark (CAR:2Y01); netconf mailing list
Subject: Re: [Netconf] Are capabilities static or dynamic ?

Andy Bierman writes:
>However, it would break the contract of any existing sessions to take 
>away or modify any capabilities each existing session already knows 
>about.  Adding new capabilities mid-session is OK, but nothing else.  
>(Operationally, a way to override that rule is probably needed.)

Sure, it's painful, but when a user removes a software module or a
license key, the abilities of the device will change.  It's unavoidable.
The options are (a) announce it, or (b) nuke any previous client
sessions.

Thanks,
 Phil

---

From: "Mark Scott" <[email-masked]>
Date: Thu, 30 Oct 2008 21:30:50 -0400

mark

-----Original Message-----
From: Phil Shafer [mailto:[email-masked]] 
Sent: Thursday, October 30, 2008 8:34 PM
To: Andy Bierman
Cc: Scott, Mark (CAR:2Y01); netconf mailing list
Subject: Re: [Netconf] Are capabilities static or dynamic ?

Thanks,
 Phil

---

From: "Mark Scott" <[email-masked]>
Date: Thu, 30 Oct 2008 22:14:14 -0400

Andy Bierman writes:
 
> The subscription already has filters, so the notification content
needs to be easily
> filtered, which means more general fields than eventTime (like
eventClass, eventSubClass, 

> I don't think "terse vs. detailed" is a good general filter though.

I was thinking different eventClass (or subclass) but filtering would
also work.

The only potential differences I see between the two approaches are in
the ability to support multiple eventDetailLevel (or different event
detail level types) in the same subscription:

With the filtering mechanism a client can only subscribe to one level of
eventDetailLevel at the time for a given eventClass (ie. one value to
match the filter).  Unless filtering were to support multi-value match.
Client can create multiple subscriptions though.

With the different eventClass a client could subscribe to both terse and
detailed events in the same subscription.

> But you are describing an extension to the <create-subscription>
parameters, right?  Or do 
> you mean the agent will generate two notifications for each event
(terse and detailed) and 
> applications will know to filter one of them out?

The client would only get what they subscribed to.

cheers,
mark

---

From: "Mark Scott" <[email-masked]>
Date: Thu, 30 Oct 2008 22:14:14 -0400

needs to be easily

parameters, right?  Or do 
(terse and detailed) and 

cheers,
mark