[Netconf] Netconf Light or Netconf for constrained devices

"Bert Wijnen (IETF)" <bertietf@bwijnen.net> Fri, 30 March 2012 08:47 UTC

Return-Path: <bertietf@bwijnen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0C321F86DD for <netconf@ietfa.amsl.com>; Fri, 30 Mar 2012 01:47:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.569
X-Spam-Level:
X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkZx6Fl9ZP5q for <netconf@ietfa.amsl.com>; Fri, 30 Mar 2012 01:47:38 -0700 (PDT)
Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id D2C6A21F86D6 for <netconf@ietf.org>; Fri, 30 Mar 2012 01:47:37 -0700 (PDT)
Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <bertietf@bwijnen.net>) id 1SDXUc-0006kU-PG for netconf@ietf.org; Fri, 30 Mar 2012 10:47:36 +0200
Received: from dog.ripe.net ([193.0.1.217] helo=dhcp-53c6.meeting.ietf.org) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from <bertietf@bwijnen.net>) id 1SDXUc-00085m-K1 for netconf@ietf.org; Fri, 30 Mar 2012 10:47:34 +0200
Message-ID: <4F757326.8090002@bwijnen.net>
Date: Fri, 30 Mar 2012 10:47:34 +0200
From: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: netconf@ietf.org
References: <80A0822C5E9A4440A5117C2F4CD36A640398E384@DEMUEXC006.nsn-intra.net>
In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640398E384@DEMUEXC006.nsn-intra.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd40b567d81c7ea34c73d973631816cac1f
Subject: [Netconf] Netconf Light or Netconf for constrained devices
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 30 Mar 2012 08:47:38 -0000

We would like to encourage the WG participants to
engage in a discussion on how to allow for
the use of NetConf for constrained devices.

See below the summary of our discussion at this weeks
session in IETF83.

Please express your opinions and pls describe
the pros and cons (as you see them) of each
possible approach.

It might also be good if someone (Andy?) could
summarize/describe how exactly one can in fact support
constrained devices with standard Netconf plus
a "deviations" approach. Maybe an example would be
the best way to demonstrate how that would be done.

Bert and Mehmet

On 3/30/12 10:32 AM, Ersue, Mehmet (NSN - DE/Munich) wrote:
> NETCONF-Light:
>
> Juergen Schoenwaelder described the updated document, which defines only
> the hello message as mandatory. Andy Bierman questioned the strategy to
> provide a solution which is competing with the current NETCONF protocol
> standard, where deviations can be used to reduce the standard features
> for an implementation. The WG was in favor of the draft however the
> issue needs to be solved and needs a discussion on the maillist as one
> of the key contributors of the draft was not present. NETCONF-Light
> makes use of the TLS Pre-Shared Key (PSK) authentication introduced in
> the update of NETCONF over TLS.