IETF Logo Mail Archive

[Netconf] additional netconf (4741bis) issues

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Sun, 08 November 2009 20:56 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BBF628C0D7 for <netconf@core3.amsl.com>; Sun, 8 Nov 2009 12:56:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.924
X-Spam-Level:
X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epsvr7ChaizB for <netconf@core3.amsl.com>; Sun, 8 Nov 2009 12:56:01 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F3DF63A67EF for <netconf@ietf.org>; Sun, 8 Nov 2009 12:56:00 -0800 (PST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 37FEAC000D for <netconf@ietf.org>; Sun, 8 Nov 2009 21:56:26 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5vwkEkeQcffF; Sun, 8 Nov 2009 21:56:25 +0100 (CET)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DBE9C000C; Sun, 8 Nov 2009 21:56:25 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 18072DA795B; Sun, 8 Nov 2009 21:56:25 +0100 (CET)
Date: Sun, 08 Nov 2009 21:56:24 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: netconf@ietf.org
Message-ID: <20091108205624.GA15523@elstar.local>
Mail-Followup-To: netconf@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: [Netconf] additional netconf (4741bis) issues
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
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: Sun, 08 Nov 2009 20:56:02 -0000

Hi,

I have a file where I collected some additional 4741bis issues. Its
getting time to get it on the table (and I am happy to do the edits if
people agree on the issues).

* clarify:

  copy-config('running', 'candidate') == commit()
  copy-config('candidate', 'running') == discard-changes()

* clarify

  any changes to 'running' must fail (check which error applies) while
  a commit is in progress

* clarify

  The handling of default data is implementation specific. Some
  implementations may choose to suppress default data while others may
  choose to always report default data while yet some other
  implementations may suppress default data as long as it was not
  explicitely set. A NETCONF extension allows to work with these
  implementation differences.

* clarify examples

  Make sure the message-id is in a proper namespace in all the
  examples. Note that attributes are not in the default namespace, so
  one has to be explicit:

    <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    </rpc>

  vs.

    <nc:rpc nc:message-id="101"
       xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
    </nc:rpc>

* incorporate capabilities text from the netconf-monitoring draft

   The
   capabilities of a NETCONF server may change over time.  However, once
   a NETCONF server has announced its capabilities in the <hello>
   message, the capabilities for that session MUST NOT change.  A server
   MUST reply with a 'capabilities-changed' error if the client sends a
   request which is affected by a modified capability.  A server MAY
   choose to send 'capabilities-changed' as the response to any request
   other than <close-session> if its capabilities has changed.

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

v2.23.0 | Report a Bug | By Email