[Netconf] FW: Document Action: 'Experience of implementing NETCONF over SOAP' to Informational RFC

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Mon, 22 September 2008 20:36 UTC

Return-Path: <netconf-bounces@ietf.org>
X-Original-To: netconf-archive@ietf.org
Delivered-To: ietfarch-netconf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745143A6B58; Mon, 22 Sep 2008 13:36:31 -0700 (PDT)
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 C404E3A6B58 for <netconf@core3.amsl.com>; Mon, 22 Sep 2008 13:36:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.061
X-Spam-Level:
X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599]
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 Z8m8bJqDIk6c for <netconf@core3.amsl.com>; Mon, 22 Sep 2008 13:36:28 -0700 (PDT)
Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 75CC63A6841 for <netconf@ietf.org>; Mon, 22 Sep 2008 13:36:28 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.32,448,1217822400"; d="scan'208";a="135743925"
Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 22 Sep 2008 16:35:54 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 22 Sep 2008 16:35:54 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 22 Sep 2008 22:35:52 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A04FA2A28@307622ANEX5.global.avaya.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Document Action: 'Experience of implementing NETCONF over SOAP' to Informational RFC
Thread-Index: AckczK//Kj0LxJFYSRW36Bv0IHgU6QAJaABQ
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: tomoyuki.iijima@alaxala.com, atarashi@alaxala.net, h-kimura@alaxala.net, makoto.kitani@alaxala.com, hideki.okita.pf@hitachi.com
Cc: netconf@ietf.org
Subject: [Netconf] FW: Document Action: 'Experience of implementing NETCONF over SOAP' to Informational RFC
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: <https://www.ietf.org/mailman/private/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: netconf-bounces@ietf.org
Errors-To: netconf-bounces@ietf.org

This document was approved by the IESG as Informational RFC. Thanks and
congratulations to the editors, and to the folks in the NETCONF
community who supported this work with their comments and reviews. 

Dan
 

-----Original Message-----
From: ietf-announce-bounces@ietf.org
[mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG
Sent: Monday, September 22, 2008 7:02 PM
To: IETF-Announce
Cc: Internet Architecture Board; RFC Editor
Subject: Document Action: 'Experience of implementing NETCONF over SOAP'
to Informational RFC 

The IESG has approved the following document:

- 'Experience of implementing NETCONF over SOAP '
   <draft-iijima-netconf-soap-implementation-10.txt> as an Informational
RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Dan Romascanu.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-iijima-netconf-soap-implementa
tion-10.txt

Technical Summary

   This document describes how the authors developed a SOAP (Simple
   Object Access Protocol)-based NETCONF client and server.  In the case
   that SOAP is used as a transport protocol for NETCONF, various kinds
   of development tools are available.  By making full use of these
   tools, developers can significantly reduce their workload.  The
   authors developed an NMS (Network Management System) and network
   equipment that can deal with NETCONF messages sent over SOAP.  This
   document aims to provide NETCONF development guidelines gained from
   the experience of implementing a SOAP-based NETCONF client and
   server.

Working Group Summary

   This document is an individual submission. Presentations were made in
   the NETCONF Working Group, the NETCONF WG chairs reviewed the 
   document but no formal review was undertaken by the WG. 

Document Quality

   The document is based upon the implementation experienced gathered by
   the authors in implementing RFC 4741 and RFC 4743. The document was
   reviewed by Dan Romascanu as Area Director, by Mehmet Ersue and Bert
   Wijnen, co-chairs of the NETCONF WG, and by Stefan Santesson for the
   security directorate. 

Personnel

   This document is an indivudual submission and Dan Romascanu is the 
   shepherding AD. 

RFC Editor Note

 RFC Editor, please make the following changes: 

1. In the Abstract Section:

OLD: 

   This document describes how the authors developed a SOAP (Simple
   Object Access Protocol)-based NETCONF client and server.  When SOAP
   is used as a transport protocol for NETCONF, various kinds of
   development tools are available.  By making full use of these tools,
   developers can significantly reduce their workload.  The authors
   developed an NMS (Network Management System) and network equipment
   that can deal with NETCONF messages sent over SOAP.  This document
   aims to provide NETCONF development guidelines gained from the
   experience of implementing a SOAP-based NETCONF client and server.

NEW: 

   This document describes how the authors developed a SOAP (Simple
   Object Access Protocol)-based NETCONF client and server. It 
   describes an alternative SOAP binding for NETCONF which does not  
   interoperate with an RFC4743 conformant implementation making 
   use of cookies on top of the persistent transport connections of
HTTP.
   
   When SOAP is used as a transport protocol for NETCONF, various kinds
of



   development tools are available.  By making full use of these tools,
   developers can significantly reduce their workload.  The authors
   developed an NMS (Network Management System) and network equipment
   that can deal with NETCONF messages sent over SOAP.  This document
   aims to provide NETCONF development guidelines gained from the
   experience of implementing a SOAP-based NETCONF client and server.

2. Add to Section 1.2 the following paragraph:

  This  document describes an alternative SOAP binding for NETCONF which
  does not interoperate with an RFC4743 conformant implementation as it
  relies on cookies used on top of the persistent transport connections
  of HTTP. This is provided for information purposes only based on the
  implementation experience of the authors. 

3. In Section 3.1.2

OLD: 

   In [RFC4743], HTTP is specified as an option of an underlying
   protocol for NETCONF over SOAP.  When HTTP is used for that purpose,
   it is also specified that a NETCONF session will be supported by an
   HTTP connection.  However HTTP is a stateless protocol; that is, HTTP
   cannot process a user's request according to the state resulting from
   the user's previous request.  Unless the state is kept at the HTTP-
   level, a different NETCONF service provider will be invoked every
   time the NETCONF application sends a NETCONF message to the NETCONF
   service provider.  To ensure that the same NETCONF service provider
   is used every time the NETCONF application sends a NETCONF message,
   the state of the HTTP connection must be maintained.  Accordingly, a
   cookie field inside an HTTP header was devised for maintaining the
   state of an HTTP connection.  We therefore used such a cookie field
   to maintain the state of the HTTP connection over which the NETCONF-
   session maintenance is ensured.

NEW: 

   In [RFC4743], HTTP is specified as an option of an underlying
   protocol for NETCONF over SOAP.  When HTTP is used for that
   purpose, it is also specified that a NETCONF session state is tied
   to the state of the underlying transport (TCP) connection (just
   like in NETCONF over SSH [RFC4742] and NETCONF over BEEP
   [RFC4744]). However, HTTP itself is a stateless protocol, and many
   server implementations process user requests independently of
   previous requests received over the same transport connection.  To
   simplify implementation of the NETCONF service provider, we used
   the cookie field inside the HTTP header to map incoming requests to
   NETCONF sessions. Note that this means our implementation actually
   uses an alternative SOAP binding for NETCONF which does not
   interoperate with RFC4743 compliant implementations.



IESG Note

This document discusses implementation experience of NETCONF over SOAP.
Note that RFC 4741 section 2.4  states, "A NETCONF implementation MUST
support the SSH transport protocol mapping". Therefore, a NETCONF
implementation that only supports the SOAP transport described in this
document and not (at least) also SSH is not in compliance with the
NETCONF standards.

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf