[netmod] AD review of draft-ietf-netmod-arch-07
"Romascanu, Dan (Dan)" <dromasca@avaya.com> Mon, 19 July 2010 15:48 UTC
Return-Path: <dromasca@avaya.com>
X-Original-To: netmod@core3.amsl.com
Delivered-To: netmod@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800DF3A6B20 for <netmod@core3.amsl.com>; Mon, 19 Jul 2010 08:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.185
X-Spam-Level:
X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.414, 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 XDhtFolxMYd3 for <netmod@core3.amsl.com>; Mon, 19 Jul 2010 08:48:09 -0700 (PDT)
Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 2E3F53A6922 for <netmod@ietf.org>; Mon, 19 Jul 2010 08:48:09 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.55,227,1278302400"; d="scan'208";a="25787012"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 19 Jul 2010 11:48:22 -0400
X-IronPort-AV: E=Sophos;i="4.55,227,1278302400"; d="scan'208";a="492889419"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Jul 2010 11:48:21 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 19 Jul 2010 17:48:17 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A040238C7A0@307622ANEX5.global.avaya.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: AD review of draft-ietf-netmod-arch-07
Thread-Index: AcsnWc4rDd048tMXSGqgbIXhJvrayQ==
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: netmod@ietf.org
Subject: [netmod] AD review of draft-ietf-netmod-arch-07
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Jul 2010 15:48:10 -0000
Please find below the AD review of draft-ietf-netmod-arch-07.txt. I found a number of issues, but none of them seems a show-stopper for me, so my proposal is to send this document to IETF Last Call, and consider these comments together with the other IETF LC comments. Unless I hear any discontent I will send the document to LC tomorrow. Thanks and Regards, Dan ------------------------------------------------------------------------ --------------- The comments are divided into Technical and Editorial. T1. Section 1.1: > Existing data modeling languages such as XSD and Relax NG were considered, but were rejected because the problem domains have little natural overlap. I do not understand this - what 'problem domains'? As I remember XSD and Relax NG were not considered sufficient because they did not meet a number of specific requirements for network device modeling, as well as some of the format needs. T2. Section 3.2: > Network-wide configuration: NETCONF supports robust network-wide configuration transactions via the confirmed-commit capability This claim sounds a little 'marketing' - why is confirmed-commit necessarily related to network-wide configuration? Is it sufficient? T3. > Implementation costs: Significant effort has been made to keep implementation costs as low as possible. Maybe. What are the results of these efforts? Do we have any information about implementation costs at this stage? How are they measured? T4. Section 3.3.4.1 - I believe that we need to discuss here the implications of the non-compliant servers on hard-coded applications. How can a developer avoid that they break? Would the deviations mechanism help in preventing at least some cases of non-compliance that can be anticipated? E1. idnits complains of several things among which the following need to be addressed: Miscellaneous warnings: ------------------------------------------------------------------------ ---- -- The document has a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. Does it really need the disclaimer? .... Checking references for intended status: Informational ------------------------------------------------------------------------ ---- .... -- Unexpected draft version: The latest known version of draft-ietf-netconf-with-defaults is -07, but you're referring to -09. -- Unexpected draft version: The latest known version of draft-ietf-netmod-yang is -12, but you're referring to -13. == Outdated reference: A later version (-06) exists of draft-ietf-netmod-dsdl-map-05 == Outdated reference: A later version (-09) exists of draft-ietf-netmod-yang-usage-05 E2. Section 1.1 - > The NETCONF specification defines a small set of operations a reference to 4741 seems to be in place at this point. E3. same - > In 2008 and 2009, the NETMOD working group produced a specification Well, we are beyond mid-2010 and the RFC is not yet approved. We should say 2008-1010 and hopefully we'll stay with this. E4. Section 2.1 - what does the list of operations in the table in page 8 include 'commit' and does not include 'delete-config', 'close-session' and 'kill-session'? E5. Section 2.3.2 > DSDL is considered to be the best choice for the given purpose What purpose? E6. Section 3.1: > The sequence of events for the typical client/server interaction is as follows: ... Note that there is no requirement for the client or server to process the YANG modules in this way. The two statements seem contradictory. If the second statement is true than in the first s/is as follows/may be as follows/ E7. Section 3.2 > YANG addresses many of the issues raised in the IAB NM workshop. s/YANG addresses/NETCONF and YANG address/ E8. > Post-processing: Use of XML will maximize the opportunities for post-processing of data, possibly using XML-based technologies like XPath, XQuery, and XSLT. References would be useful
- [netmod] AD review of draft-ietf-netmod-arch-07 Romascanu, Dan (Dan)
- Re: [netmod] AD review of draft-ietf-netmod-arch-… Phil Shafer
- Re: [netmod] AD review of draft-ietf-netmod-arch-… Romascanu, Dan (Dan)