Subject: [netmod] Last Call: draft-ietf-netmod-smi-yang-01 (20110704)

From: David Kessens <[email-masked]>
Date: Thu, 14 Jul 2011 09:45:07 -0700

I would hereby like to issue a Last Call for:

http://tools.ietf.org/html/draft-ietf-netmod-smi-yang-01

The draft has stabilized enough that it is getting time to go to the next
stage and in order to do so, we need to determine whether it is ready to be
submitted to the IESG with a requested status of Proposed Standard.

I would like to see at least three supporting statements by July 4, 2011 by
people who reviewed the document and feel it is ready for publication.
Obviously, it would be far preferred if we get more reviews, and especially
reviews before our next scheduled meeting in Quebec which would allow us to
hash out any potential issues during the meeting.

David Kessens
PS My co-chair, Juergen Schoenwaelder, is the author of this document and
   I will therefore handle this document.
---

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 Jul 2011 09:59:27 -0700

> http://tools.ietf.org/html/draft-ietf-netmod-smi-yang-01

You mean August 4th I think.
There are already companies using yangcli to manage smidump-converted
modules, running in confd.  We really need to freeze the spec soon.
(You can consider this a supporting statement.)

Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>
>

---

From: David Kessens <[email-masked]>
Date: Thu, 14 Jul 2011 12:29:27 -0700

Andy,

> You mean August 4th I think.

Fixed.

> (You can consider this a supporting statement.)

Can you indicate whether you read and reviewed the current version of the
draft ? We need to make sure that the latest version received enough
review before sending it on to the IESG.

David Kessens
---

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 Jul 2011 12:39:30 -0700

> review before sending it on to the IESG.

oh -- I was hoping to avoid the latest details, but since you asked, I will read
the latest draft.  I have confidence in the author and other WG members
that they will work out the issues on extension statements, etc.
I am happy enough with the data naming and other important details.

I think the read-only stance will run into problems in real implementations
for spot leafs here and there, maybe whole modules.  I think (despite
all the warnings) some people will edit the YANG generated from the standard algorithm.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 24 Jul 2011 13:56:22 -0400 (EDT)

Hi,

I have reviewed this document, and I think it is ready for
publication, with some (mostly minor) edits:

Section 3

  When you read this document from the beginning, it is not clear what
  this section is for.  Later in the document there are backwards
  references to it, so it gets clear.  I suggest to add a sentence in
  the beginning of section 3, which says something like: "This section
  describes an algorithm to generate unique module prefixes, to be
  used in the import statements."

Table 2

  Says "YANG / SMIv2 Module".  Should be only YANG module?

  If so, also

    s/well known SMIv2 and YANG modules/well known YANG modules/g

Section 3

  This section talks about "module name", "SMIv2 module name".  I
  think it should only mention "YANG module name".  Now, since the
  YANG module name is later defined to be the SMIv2 module name, it
  doesn't really matter for the end result, but it is clearer if the
  alg. describes how a prefix (which is a YANG construct) is generated
  from the YANG module name.

  s/by tokenizing an SMIv2 module name/
    by tokenizing the YANG module name/

  s/The tokens derived from a module name/
    The tokens derived from the module name/

  s/shortest sequence of token/
    shortest sequence of tokens/

  s/at least two token/at least two tokens/

Section 4

  s/constant prefix, which followed/
    constant prefix followed/

Table 3

  This table explicitly lists some SNMPv2-SMI symbols, and then
  there's a catch all clause that all SNMPv2-SMI symbols are ignored
  during import.  I suggest the explicit symbols are removed.

Table 3

  This table and following text says that all symbols in
  SNMPv2-CONF are translated by translation rules.  But there are no
  translation rules for the macros in SNMPv2-CONF.  I suggest you add
  a section that describes how these macros are handled - i.e., that
  they are not translated at all.

Table 3

  This table lists 'snmpTraps' from SNMPv2-MIB.  But why is that one
  special?  Suppose someone imported 'snmpMIBObjects' from
  SNMPv2-MIB.  Why is this different?

Section 4

  "according to the type mapping table"

  Add a reference "according to the type mapping table (see table 1)"

Section 4

   "This requires to consider all the types used in the translation
   unit"

  What is a translation unit?

Section 4.1

   "The translation of the IF-MIB [RFC2863] leads to the YANG module
   frame"

  What is a module frame?

Section 5.1

   "Furthermore, SMIv2 modules generated from SMIv1 modules may miss an
   invocation of the MODULE-IDENTITY macro as well"

   So what will the top-level container be in this case?

   Since the concept of a top-level container is used later in the
   translation, this needs to be specified.

Section 7

  "OBJECT IDENTIFIER assignments are not translated into YANG
  statements"

  Isn't this what the new smiv2:alias statement was supposed to be
  used for?

Section 8.1

   "All leaf statements for scalar objects are created in the top-level
   container"

  OK -- but I just want to point out that this leads to a model where
  you need to be careful with using filters if you don't want to get
  all data for a module.

Section 8.4

     container ifTable {
       config false;

  where did the config false statement come from?

  Ok, it's not wrong, but unnecessary.  It's perfectly fine if your
  implementatiomn generates it, but it should be removed from this
  example, otherwise a reader might think he missed something.

Section 8.6

  I think the name, description, reference and value of the augmenting
  OBJECT-TYPE should not be captured in comments, but in a smiv2:alias
  statement.  For example:

  OLD:

     /*
      * ifXTable (1.3.6.1.2.1.31.1.1)
      *
      * A list of interface entries.  The number of entries is
      * given by the value of ifNumber.  This table contains
      * additional objects for the interface table.
      */

  NEW:

    smiv2:alias ifXTable {
      smiv2:oid "1.3.6.1.2.1.31.1.1";
      description
        "A list of interface entries.  The number of entries is
        given by the value of ifNumber.  This table contains
        additional objects for the interface table.";
    }

s/""/"/g

Section 9.

   The SMIv2 uses invocations of the OBJECT-IDENTITY macro to define
   information about an OBJECT IDENTIFIER assignment.  Invocations of
   the OBJECT-IDENTITY macro MUST be translated into YANG identity
   statements as detailed below.

  Ok, but in this case, from the MALLOC-MIB, this will be somewhat
  odd...

madcapConfig OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "Group of objects that count various MADCAP events."
    ::= { madcap 1 }

/martin