Subject: [netmod] I-D Action: draft-ietf-netmod-smi-yang-02.txt

From: [email-masked]
Date: Fri, 25 Nov 2011 03:26:31 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

	Title           : Translation of SMIv2 MIB Modules to YANG Modules
	Author(s)       : Juergen Schoenwaelder
	Filename        : draft-ietf-netmod-smi-yang-02.txt
	Pages           : 41
	Date            : 2011-11-25

   YANG is a data modeling language used to model configuration and
   state data manipulated by the NETCONF protocol, NETCONF remote
   procedure calls, and NETCONF notifications.  The Structure of
   Management Information (SMIv2) defines fundamental data types, an
   object model, and the rules for writing and revising MIB modules for
   use with the SNMP protocol.  This document defines a translation of
   SMIv2 MIB modules into YANG modules, enabling read-only access to
   data objects defined in SMIv2 MIB modules via NETCONF.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netmod-smi-yang-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-smi-yang-02.txt

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 25 Nov 2011 12:30:33 +0100

> 	Filename        : draft-ietf-netmod-smi-yang-02.txt

Please review the changes and let me know in case I messed something
up. This revision closes all open issues again and in case I did not
mess things up badly, I hope we can continue with the process.

/js

PS: The SVN version of libsmi follows this revision except the import
    generation part - perhaps I can get that implemented in the coming
    days as well.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 28 Nov 2011 12:19:18 +0100 (CET)

Hi,

Juergen Schoenwaelder <[email-masked]> wrote:
> Please review the changes

o  Since you added an example from RMON2-MIB, you may want to list it
   in the Introduction, where you list IF-MIB and DIFFSERVER-MIB.

o  Section 2

     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 [RFC6021].

   Add ietf-yang-smiv2 to this list (for the Opaque type).  Ok, if
   extensions are generated it will be added anyway...

o  With the new mapping of well-known TCs, it is a bit confusing what
   happens when the SMIv2 MIB module with the TC is translated.  For
   example, when a TruthValue is used, it is translated to a YANG
   boolean, but when SNMPv2-TC is translated, you will get a typedef:

      typedef TruthValue {
        type enumeration {
          enum "true"  { value "1"; }
          enum "false" { value "2"; }
        }
        description
         "Represents a boolean value.";
      }

   There is no technical problem with this; it is just a bit
   confusing.

   An alternative could be to do the static mapping in the translation
   of the TC itself.  So a TruthValue object would be translated to
   SNMPv2-TC:TruthValue, but the TC would be translated to:

      typedef TruthValue {
        type yang:boolean;
        description
         "Represents a boolean value.";
      }

o  Last bullet in section 3:

   o  Generate an import statement for the yang module ietf-yang-smiv2
      with the prefix smiv2 if extensions from ietf-yang-smiv2 will be
      used in the translated yang module.

   The "if" part should be removed, since the extensions are
   mandatory to generate.

o  Section 4.1

   o  The name of the SMIv2 module is used to generate a top-level
      container statement.  This container MUST be config false.

   I suggest this container is not generated if there are no objects
   in the SMIv2 module.  (For example, running smidump on SNMPv2-TC
   gives:

      container SNMPv2-TC {
        config false;
      }

   this looks odd, and is not needed)

   Also, the idea is that the container name is the same as the SMIv2
   module name; this should be stated explicitly.

o  Section 7.1

     Leaf statements for scalar objects are created in a container
     representing the scalar's parent node in the OID tree.  This
     container is is named after the scalar's parent node in the OID
     tree and placed in the top-level container representing the SMIv2
     module, see Section 4.1.

   s/is is/is/

     In the rare case that the scalar's parent node has multiple
     names, the automatic translation MUST fail with an error and the
     name clash needs to be investigated and fixed manually.

  Are there any rules for how to fix this manually, or can it be
  "fixed" differently by different persons?  The rules could be that
  if there exists a previous revision of the module, the same node as
  used in the previous revision must be used.  Otherwise (no previous
  revision), the first name must be used.

o  Section 7.6

  The YANG snippet has strings w/o the concatenation operator, and
  an erroneous double quote:

           path "/rmon2-mib:RMON2-MIB/"
                "rmon2-mib:protocolDirTable/"
                "rmon2-mib:"protocolDirEntryf/"
                "rmon2-mib:protocolDirLocalIndex";
         }

  should be

           path "/rmon2-mib:RMON2-MIB/"
              + "rmon2-mib:protocolDirTable/"
              + "rmon2-mib:protocolDirEntryf/"
              + "rmon2-mib:protocolDirLocalIndex";
         }

o  Appendix A

  s/Yang/YANG/g

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Nov 2011 14:57:56 +0100

>    in the Introduction, where you list IF-MIB and DIFFSERVER-MIB.

fixed 
 
>    extensions are generated it will be added anyway...

fixed 
 
>          "Represents a boolean value.";

Since there is no technical problem I prefer to leave this as it is.
 
>    The "if" part should be removed, since the extensions are

fixed

>    module name; this should be stated explicitly.

While sometimes the generation of the container can be skipped, it is
not wrong to generate one. If you want to prune the container, what
about a module defining only and a table augmentation?  You also would
prune, right? I think we should make this a MAY. What about this text:

- A top-level YANG container is generated. The container's name is the
  SMIv2 module name and the container MUST be config false.  The
  generation of the top-level container MAY be skipped if the SMIv2
  module does not define any objects that go into the top-level
  container (e.g., an SMIv2 module only defining textual conventions).
 
>      tree and placed in the top-level container representing the SMIv2

fixed
 
>   revision), the first name must be used.

well, hopefully the human is smart ;-) I added this:

In case a previous revision of the SMIv2 module did not have an
ambiguity, then the name used by the previous revision MUST be used.
 
>               + "rmon2-mib:protocolDirLocalIndex";

fixed (I hope ;-)
 
>   s/Yang/YANG/g

fixed

/js

---

From: David Spakes <[email-masked]>
Date: Mon, 28 Nov 2011 11:00:38 -0500 (EST)

> mess things up badly, I hope we can continue with the process.

On page 23, the type of leaf ifName is snmpv2-tc:DisplayString, but
that does not match Section 3.1.  Prefix smiv2-tc seems to be left
over from an earlier revision.

s/smiv2-tc/snmpv2-tc/

-dss

-------------------------------------------------------------
 David Spakes                       email:   [email-masked]
 SNMP Research                      voice:   +1 865 573 1434
 3001 Kimberlin Heights Road          fax:   +1 865 573 9197
 Knoxville, TN  37920-9716  USA      http://www.snmp.com
-------------------------------------------------------------

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Nov 2011 17:08:31 +0100

> over from an earlier revision.

Thanks, fixed.

/js

---

From: David Reid <[email-masked]>
Date: Tue, 29 Nov 2011 17:10:27 -0500

> mess things up badly, I hope we can continue with the process.

   4.1.  MODULE-IDENTITY Translation Rules

      ...

      o  The object identifier value of the invocation of the SMIv2 MODULE-
         IDENTITY is translated into an smiv2:oid statement contained in
         the container representing the MODULE-IDENTITY macro invocation.
         Refer to the YANG extension defined in Section 10.

Since we are not translating the MODULE-IDENTITY to a container, should it
be translated to an smiv2:alias statement with an embedded smiv2:oid
statement?

-David Reid

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Nov 2011 08:37:24 +0100

> be translated to an smiv2:alias statement with an embedded smiv2:oid

Yes. Changed this to:

   o  The object identifier value of the invocation of the SMIv2 MODULE-
      IDENTITY is translated into an smiv2:oid statement contained in an
      smiv2:alias statement representing the MODULE-IDENTITY macro
      invocation.  Refer to the YANG extension defined in Section 10.

/js