Subject: [netmod] New AD review of draft-ietf-netmod-smi-yang-04

From: Benoit Claise <[email-masked]>
Date: Thu, 19 Apr 2012 14:12:02 +0200

Juergen,

I'm performing the (new) AD review of draft-ietf-netmod-smi-yang-04.
Lucky you, an extra pair of eyes specifically looking at your draft

- 1.  Introduction

    This document describes a translation of SMIv2 [RFC2578], [RFC2579],
    [RFC2580] MIB modules into YANG [RFC6020] modules, enabling read-only
    access to data objects defined in SMIv2 MIB modules via NETCONF.  The
    mapping is illustrated by examples showing the translation of parts
    of the IF-MIB [RFC2863], the DIFFSERV-MIB [RFC3289], and the RMON2-
    MIB [RFC4502] SMIv2 module.

read-only access of read-only MIB variables, or read-only access of 
read-only and read-write MIB variables.
I guessed the former, but, while reading through the draft, I was always 
wondering: Why do we have this limitation?
After reading the entire draft, I found the answer in section 11.
We should have at a very minimum a pointer somewhere in the intro, with 
a sentence such as: "the reasons why ... are explained in section 11", 
or even better the explanation way earlier in the draft... for example 
in the intro.

- Section 11.  Implementing Configuration Data Nodes

    The translation of SMIv2 MIB modules into YANG modules defined above
    is read-only.

The translation are not read-only: "The results of the translation of 
SMIv2 MIB modules into YANG modules, even if objects are read-write, 
consists of read-only objects."

-    SMIv1 modules may be converted to YANG by first following the rules
    in [RFC3584] to convert the SMIv1 module to SMIv2, then following the
    rules in this document to convert to YANG.

I thought it was a MUST? SMIv1 modules MUST be first converted to SMIv2 
before...
Replacing "SMIv1 modules may be converted" by "SMIv1 modules can be 
converted" would also solve it.

- Section 2.  Mapping of Well Known Types

   The mappings shown in Appendix A may impact the imports of the
    generated YANG module since some SMIv2 types and textual conventions
    map to YANG types defined in the ietf-yang-types and ietf-inet-types
    YANG modules defined in [RFC6021] and the ietf-yang-smiv2 YANG module
    defined in this document.

What do you mean by "may impact"? You want to say that you may have to 
import the ietf-yang-types and ietf-inet-types YANG modules?

- Section 3.  Translation of SMIv2 Modules and SMIv2 IMPORT Clauses

    SMIv2 modules are mapped to corresponding YANG modules.  The YANG
    module name MUST be the same as the SMIv2 module name.

... when doing the translation, when the information model is the same, 
or when ...

- Remember the discussion in OPS-DIR about documentating all the SMI 
TCs. Will we have the same issues with YANG typedef?
I see two solutions:
1. We document all the typedef on a WIKI
     Pros: not much administration, a simple script can extract all the 
typedef from the IETF YANG modules
     Cons: need to be maintained (basically, all the IETF MIB modules 
must reside at the same location)
2. We ask IANA to maintain the typedef for us
     Cons: extra process: every new typdef in YANG module must be 
registered in IANA

- Section 4.1
    o  Each SMIv2 REVISION clause is mapped to a YANG revision statement.
       The revision is identified by the date argument of the SMIv2
       REVISION clause.  DESCRIPTION sub-clauses of REVISION clauses are
       mapped to corresponding description statement nested in revision
       clauses.

Do you see an issue with an initial MIB module, translated into a YANG 
module, then both the MIB modules and YANG modules are updated 
independently? What's happening in this case with the "revision" and 
"prefix"?
Some more guidelines in such a case would be welcome.

-   leaf protocolDirLocalIndex {
          type leafref {
            path "/rmon2-mib:RMON2-MIB/"
               + "rmon2-mib:protocolDirTable/"
               + "rmon2-mib:protocolDirEntryf/" <------------------- f ?
               + "rmon2-mib:protocolDirLocalIndex";
          }
        }

        // ...

        leaf protocolDirLocalIndex_2 {
          type leafref {
            path "/rmon2-mib:RMON2-MIB/"
               + "rmon2-mib:protocolDirTable/"
               + "rmon2-mib:protocolDirEntry/"
               + "rmon2-mib:protocolDirLocalIndex";
          }
        }

- Appendix A.  Mapping of Well Known Types (normative)
Would be nice to express that
1. this is fully in line with table 1 and table 2 in RFC6020
2. it complements these tables

- please address 
http://www.ietf.org/mail-archive/web/netmod/current/msg06534.html

- please address 
http://www.ietf.org/mail-archive/web/netmod/current/msg06484.html

- please address the security directory review "secdir review of 
draft-ietf-netmod-smi-yang-04", from [email-masked]

Regards, Benoit.