Subject: [netmod] comments on draft-ietf-netmod-smi-01

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Jul 2011 08:15:32 -0700

Hi,

This draft is ready for advancement to the IESG.
Here are my review comments.  Just clarifications requested.

sec 2:

    Implementations are encouraged to provide
    options to handle situations where DISPLAY-HINTs are added during a
    revision of a module and backwards compatibility must be preserved.

What are the options they are encouraged to provide?

sec 3:

The order modules are processed by a translator will affect the
prefix algorithm, wrt/ detecting conflicts.   It seems this algorithm is
ad-hoc, and there is no way to determine if the shortest unique
prefix is really found.  IMO it would be better to allow a translator
to use the entire converted module name to be sure the prefix is unique.

sec. 4:

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

Do you mean the converted module name, according to the algorithm in sec. 3?
No.  I see further down this is not the case.  I suggest a new section
called Mapping of the Module Name to make this more clear.

sec. 4:

    The generated import statements use the untranslated SMIv2 module
    names or the names of well-known YANG modules as their argument

I don't understand why the module name is unchanged but the generated
prefix is changed (e.g., all lowercase).

sec 6.1:

OLD:

    o  The SMIv2 DISPLAY-HINT MAY be translated into an smiv2:display-
       hint statement, see the YANG extension defined in Section 11.

NEW:

    o  The SMIv2 DISPLAY-HINT MAY be translated into an smiv2:display-
       hint statement.  Refer to the YANG extension defined in Section 11.

      SMIv2 INTEGER enumerations and SMIv2 BITS are mapped to YANG enum
       / value and bit / position statements.

Are these forward slashes typos?  (also sec. 8.1)

sec 6.3 (enum translation example)

It would be nice to start using the YANG style of documenting enums by
putting the semantics of each enum in its own description-stmt, instead
of all together in the typedef or object description.  But this cannot
be done automatically, so it cannot be done.

   *** Side issue: will this spec be used by MIB designers to help manually
   *** convert their MIB design patterns to YANG?  If so, then guidance
   *** on this sort of manual conversion would be useful to them.

sec. 8.3:

    YANG leaf statements of type leafref pointing to the
    referenced definition are created.

then later in 8.5:

         leaf ifIndex {
            type leafref {
              path "/if-mib:ifMIB/if-mib:ifTable" +
                   "/if-mib:ifEntry/if-mib:ifIndex";
            }
            description
             "[Automatically generated leaf for a foreign index.]";
          }

The text does not mention this automatic description-stmt.
Should the text say this string SHOULD (or MAY) be used?

Andy