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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 22 Mar 2012 11:49:33 +0100

Please find below the AD review of draft-ietf-netmod-smi-yang-04. The
document is in good shape and I am sending it to IETF Last Call. Please
consider the comments below together with the other IETF LC comments. 

Technical comments are marked with a T, Editorial Comments are marked
with an E. 

T1. In Section 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.

It is not clear how this is realized. How can the possible DISPLAY-HINTs
be anticipated, what options could be provided? 

Also is 'are encouraged' similar to a MAY? The next paragpraph uses a
2119 keyword. 

T2. In Section 10: 

  extension max-access {
    argument "access";
    description
     "The max-access statement takes as an argument the MAX-ACCESS
      assigned to an SMIv2 object definition";
    reference
     "RFC2578: Structure of Management Information Version 2 (SMIv2)";
  }

However the introduction says

   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 statement in the introduction seems contradictory with the
description. What happens if the MAX-ACCESS indicates that the object is
writeable? 

Moreover section 11 starts with the statement: 

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

nnd continues with defining configuration nodes as an exception that
needs to be documented. 

What am I missing?

E1. In Section 5.2: 

   The translation of the OwnerString and InterfaceIndex textual
   conventions of the IF-MIB [RFC2863] are shown below.

s/translation/translations/

Regards,

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 22 Mar 2012 12:26:24 +0100

> consider the comments below together with the other IETF LC comments. 

Dan,

thanks for your review. Let me quickly followup on your technical comments.

> Also is 'are encouraged' similar to a MAY? The next paragpraph uses a

Its about an option that can be used to translate the new module as if
the added DISPLAY-HINTs would not be there. I would have to think about
better wordings. Something like:

  smidump -f yang --yang-ignore-display-hint=fooObject FOO-MIB

(Not that I have implemented this yet but I probably should.)

Since the text talks about implementation specific options that are
not part of the translation algorithm itself, I ended up using a
phrase like "encouraged". I admit that I am pretty bad in proper RFC
2119 keyword usage.

> description. What happens if the MAX-ACCESS indicates that the object is

The generated YANG module only has "config false" definitions. The
smiv2:max-access extension just carries the originial SMIv2 access so
that it is not lost - it does not change the fact that the YANG
definition is "config false".

> nnd continues with defining configuration nodes as an exception that

Section 11 provides guidance: if an implementation chooses to
implement a "config false" YANG object as "config true", then this
needs to be properly declared using the YANG deviation mechanism. The
YANG module generated by the translation rules remains read-only.

/js

-- 
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/>