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

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

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
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: list

Hi,

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 {
description
"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.

Best,

Rolf

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

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