[Netconf] dynamic capabilities

Martin Bjorklund <mbj@tail-f.com> Mon, 06 April 2009 20:27 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 64A0C3A6D4A for <netconf@core3.amsl.com>; Mon, 6 Apr 2009 13:27:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.677
X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=-1.231, BAYES_50=0.001, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id DYZETe8PjZO9 for <netconf@core3.amsl.com>; Mon, 6 Apr 2009 13:27:30 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se []) by core3.amsl.com (Postfix) with ESMTP id 8F0B33A6D41 for <netconf@ietf.org>; Mon, 6 Apr 2009 13:27:30 -0700 (PDT)
Received: from localhost (c213-100-167-236.swipnet.se []) by mail.tail-f.com (Postfix) with ESMTPSA id F1652616028 for <netconf@ietf.org>; Mon, 6 Apr 2009 22:28:34 +0200 (CEST)
Date: Mon, 06 Apr 2009 22:28:33 +0200
Message-Id: <20090406.222833.252436646.mbj@tail-f.com>
To: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: [Netconf] dynamic capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Apr 2009 20:27:31 -0000


This is an issue that needs to be clarified in 4741bis, and it needs
to be resolved before the monitoring draft can be completed (as noted
at IETF74).

The question is if a server is allowed to dynamically change its
capability list, as advertised in the <hello> message, during the
lifetime of a session.

One solution is to say that a server MUST NOT change its capability
list in ongoing sessions.  This makes it very clear and easy for the
client.  The question is what to do with existing sessions if the
supported capabilities change.  They could be killed by the server, or
enter a state where commands related to changed capabilities would

An alternative is to say that servers are allowed to change its
capabilities on the fly.  But then the question is how a client can
tell that this happened?  Some people have suggested that a
notification can be used, but unless the :interleave capability is
supported, this would require each client to have a separate session
to monitor this.

Personally, I prefer the first alternative b/c it is simpler.  I think
it will be difficult to make the second alternative work.

Comments?  Other solutions?