tsv-dir review of draft-ietf-netconf-4741bis-07

Rolf Winter <Rolf.Winter@neclab.eu> Fri, 04 February 2011 12:34 UTC

Return-Path: <Rolf.Winter@neclab.eu>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 52CDA3A6956; Fri, 4 Feb 2011 04:34:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.418
X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 4SvarIbkjGMO; Fri, 4 Feb 2011 04:34:44 -0800 (PST)
Received: from smtp0.neclab.eu (smtp0.neclab.eu []) by core3.amsl.com (Postfix) with ESMTP id 521E33A6941; Fri, 4 Feb 2011 04:34:44 -0800 (PST)
Received: from localhost (localhost.localdomain []) by smtp0.neclab.eu (Postfix) with ESMTP id F411A2C000409; Fri, 4 Feb 2011 13:39:13 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd)
Received: from smtp0.neclab.eu ([]) by localhost (atlas2.office.hd []) (amavisd-new, port 10024) with ESMTP id mAb7NhVFIrUM; Fri, 4 Feb 2011 13:39:13 +0100 (CET)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd []) by smtp0.neclab.eu (Postfix) with ESMTP id C175B2C000406; Fri, 4 Feb 2011 13:38:53 +0100 (CET)
Received: from DAPHNIS.office.hd ([]) by ENCELADUS.office.hd ([]) with mapi id 14.01.0270.001; Fri, 4 Feb 2011 13:37:48 +0100
From: Rolf Winter <Rolf.Winter@neclab.eu>
To: "tsv-dir@ietf.org" <tsv-dir@ietf.org>, "tsv-area@ietf.org" <tsv-area@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-netconf-4741bis@tools.ietf.org" <draft-ietf-netconf-4741bis@tools.ietf.org>
Subject: tsv-dir review of draft-ietf-netconf-4741bis-07
Thread-Topic: tsv-dir review of draft-ietf-netconf-4741bis-07
Thread-Index: AcvEaFPgjVChlilzTTCe0WJ6/3YvVQ==
Date: Fri, 04 Feb 2011 12:37:48 +0000
Message-ID: <791AD3077F94194BB2BDD13565B6295D8ED1FC@DAPHNIS.office.hd>
Accept-Language: en-US, de-DE
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Feb 2011 12:34:45 -0000


I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review.  

This draft is basically ready for publication, but has nits that should be fixed before publication. There are no transport-related concerns that I could spot.

Some nits:

Section 2.1: second paragraph (below), second sentence doesn't parse quite right for me. Especially as the following sentence seems to imply the opposite. I read this as "The client can change things that cannot be changed"

--> "NETCONF connections are long-lived, persisting between protocol
operations.  This allows the client to make changes to the state of
the connection that will persist for the lifetime of the connection.
For example, authentication information specified for a connection
remains in effect until the connection is closed."

You have "Authentication" in titles twice (in 2.2 and 2.3). Can do without in 2.2 as you dedicate a whole section on it.

Section 2.2. "NETCONF connections must" is not a "MUST". Is this intentional (BTW, you don't mention integrity in the security considerations section any more).

"NETCONF transport protocols therefore MUST explain how a NETCONF username is
derived from the authentication mechanisms supported by the transport
protocol." I read this as every transport protocol that NETCONF can run over (SSH e.g.) needs to specify this, but I think this is not what you require or even can ask for. But maybe I misunderstand the sentence.

Regarding this error:
enum operation-failed {
            "Request could not be completed because the requested
             operation failed for some reason not covered by
             any other error condition.";
This is send if the XML is not well formed. Maybe you could dedicate a message to this that makes trouble shooting a little easier such as "XML-format-error" or something.

That's about it.



NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014