Subject: [netmod] smi2yang-02: update ambiguity of named INTEGERs and BITS

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Apr 2011 12:01:34 +0200

* smi2yang-02: update ambiguity of named INTEGERs and BITS

  SMIv2 allows the descriptors of enumerated INTEGERs and named BITS
  to change during revisions. YANG does not allow enums to be changed.

** Solution #02-01:

   Declare this a non-problem since label changes are rare. Hm.

** Solution #02-02

   Do generate artificial labels that use the number and add the SMIv2
   label via an smiv2 extension statement. This leads to rather ugly
   instance documents.

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

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 09 Apr 2011 13:12:49 +0200 (CEST)

Hi,

>    Declare this a non-problem since label changes are rare. Hm.

I prefer this solution.  See also #04.

>    label via an smiv2 extension statement. This leads to rather ugly

Yes.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Apr 2011 09:33:22 +0200

> >    label via an smiv2 extension statement. This leads to rather ugly

I think we are kind of lucky since I found this text in RFC 4181:

   - Bullet (1) allows the labels of named numbers and named bits in
     SYNTAX clauses of type enumerated INTEGER or BITS to be changed.
     This can break compilation compatibility, since those labels may be
     used by DEFVAL clauses in modules that import the definitions of
     the affected objects.  Therefore, labels of named numbers and named
     bits MUST NOT be changed when revising IETF MIB modules (except to
     correct typographical errors), and they SHOULD NOT be changed when
     revising enterprise MIB modules.

In other words, it is already documented in an RFC that changing
labels in MIB modules is a bad idea in the first place. I will add
text pointing to Section 4.9 of RFC 4181 and this issue is closed.

/js