[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