[netmod] AD review of draft-ietf-netmod-dsdl-map

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Thu, 19 August 2010 16:58 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 18ED33A6A30 for <netmod@core3.amsl.com>; Thu, 19 Aug 2010 09:58:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.56
X-Spam-Level:
X-Spam-Status: No, score=-101.56 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_20=-0.74, USER_IN_WHITELIST=-100]
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 XKhxMvwnlWBF for <netmod@core3.amsl.com>; Thu, 19 Aug 2010 09:58:19 -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 E00333A68CB for <netmod@ietf.org>; Thu, 19 Aug 2010 09:58:18 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.56,234,1280721600"; d="scan'208";a="30662036"
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 Aug 2010 12:57:17 -0400
X-IronPort-AV: E=Sophos;i="4.56,234,1280721600"; d="scan'208";a="505193233"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Aug 2010 12:57:17 -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: Thu, 19 Aug 2010 18:56:55 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A040246CFC5@307622ANEX5.global.avaya.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: AD review of draft-ietf-netmod-dsdl-map
Thread-Index: Acs/v4eruw8YCyUUT8eSz/h8N/3UWQ==
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: NETMOD Working Group <netmod@ietf.org>
Subject: [netmod] AD review of draft-ietf-netmod-dsdl-map
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: Thu, 19 Aug 2010 16:58:21 -0000

Please find below my AD review for draft-ietf-netmod-dsdl-map-06.txt. I
believe that a revised I-D is needed before proceeding to IETF Last
Call. Also, you need to answer issue T1 either by moving the reference
to 5013 to Informational, or by specifying the downref in the IETF Last
Call. 

The comments are divided into Technical and Editorial. 


T1. There is a normative reference to RFC 5013 which is Informational.
This is a downref. If this reference must be normative, the downref must
be explicitly mentioned in the IETF Last Call. Is this the intention? 

T2. Introduction 

> The NETMOD Working Group was
   chartered to address this problem by defining a new human-friendly
   modeling language based on SMIng [RFC3216] and called YANG [YANG].

I do not believe that this statement is true. There was no requirement
in the charter to base the YANG on SMIng.

T3. Section 8.4: 

> Each embedded <rng:grammar> element must declare the namespace of
       the corresponding module using the @ns attribute.

Use capitalized MUST. 

T4. Section 10.13

> This statement MAY be ignored.  Otherwise, it is mapped to the DTD
   compatibility element <a:documentation> and ARGUMENT becomes its
   text.

What does the second sentence mean? What to do when mapping or what not
to do? 

T5. Same question as above for 10.47

T6. Section 10.56: 

> Implementations MAY ignore this statement.

Why?

T7. Section 10.60: 

> This statement is not mapped to the output schema.  However, an
   implementation SHOULD check that it is compatible with the YANG
   version declared by the statement (currently version 1).

What should an implementation do if the yang-version is not compatible?
(which may happen in the future)

T8. Section 11:

> In general, the second mapping step has to accomplish the following
   three tasks:

What does 'In general' mean here? Are there exceptions? Which ones? 






E1. Introduction: s/SNMP Management Information Bases (MIBs)/SNMP
Management Information Base (MIB) modules/

E2. Expand acronyms at the first occurrence: DSRL, etc.

E3.In section 3: s/the inverse mapping from DSDL to YANG beyond the
scope of this document/the inverse mapping from DSDL to YANG is beyond
the scope of this document/

E4. Section 4 - reference for ISO/IEC 19757, RelaxNG, Schematron, DSRL
are desirable in the introduction part of the section. 

E5. I see no reason to list the URIs separately and format them
separately then the rest of the Informative references. Actually [XSD]
is also referenced by an URI, although included with the other
references. 

E6. In section 8.2 s/SNMP MIBs/SNMP MIB modules/

E7. The non-usage of quotation marks in the titles of subsections in 10
is confusing. For example should not 10.11 be The 'container' Statement
rather than The container statement - so that the use of the noun
container in the text can be differentiated from the name of the
statement? Or in 10.12 we have The default Statement as the title of the
subsection while the text of the section speaks about the 'default'
statement. 

E8. Section 12: s/we will denote CONTELEM/we will call CONTELEM/

E9. The IANA considerations section mentions registering three namespace
URIs, but then lists only two. 

E10. Make explicit that Appendix D will be removed at document
publication.