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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 22 March 2012 11:26 UTC

Date: Thu, 22 Mar 2012 12:26:24 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Message-ID: <20120322112624.GB22237@elstar.local>
Mail-Followup-To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, netmod@ietf.org
References: <EDC652A26FB23C4EB6384A4584434A0407638D5F@307622ANEX5.global.avaya.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A0407638D5F@307622ANEX5.global.avaya.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-smi-yang-04
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>

On Thu, Mar 22, 2012 at 11:49:33AM +0100, Romascanu, Dan (Dan) wrote:
> 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. 

Dan,

thanks for your review. Let me quickly followup on your technical 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. 

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.

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

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".

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

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

[netmod] AD review of draft-ietf-netmod-smi-yang-… Romascanu, Dan (Dan)
Re: [netmod] AD review of draft-ietf-netmod-smi-y… Juergen Schoenwaelder