Subject: Re: [netmod] mib to yang conversion: 2 more issues

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Nov 2011 17:13:00 +0100

On Mon, Oct 10, 2011 at 05:26:30PM -0400, David Reid wrote:
> 
> Here are a couple more issues with the mib to yang conversion and proposed
> solutions.
> 
> Problem:
> If a table index is accessible-for-notify, it is not translated to yang.
> For example, in MIP-MIB (RFC 2006), the object mipSecViolatorAddress is 
> a table index and has a MAX-ACCESS of accessible-for-notify. According 
> to the current conversion rules (section 8.1), mipSecViolatorAddress 
> will be dropped. But since it is a table index, it must be preserved.
> 
> Proposed Solution: 
> Add the following sentence as the second sentence in section 1.8: 
> Additionally, columnar objects with a MAX-ACCESS of accessible-for-notify 
> are translated to YANG leaf statements if that columnar object is part of 
> the INDEX clause of the table containing that columnar object.

Yes, this makes sense. I have added the sentence you suggested. 
 
> Problem:
> RMON2-MIB (RFC 4502) has an INDEX clause in which the same object appears
> twice. Specifically, alHostEntry's INDEX clause uses protocolDirLocalIndex
> twice. Following the current conversion rules results in a translated
> document that violates the YANG rule that a leaf identifier MUST NOT appear 
> more than once in the key.
> 
> Proposed Solution:
> Section 8.3 in the last bullet point on page 15, add a sentence somthing
> like this: If the same object appears more than once in the INDEX
> clause, append -<n> to the second and subsequent duplicate object names 
> where <n> is a number representing the number of times that object has
> appeared up to this point in the INDEX clause. [not sure I stated that
> clearly. I'm trying to say that the key statement for alHostEntry should be
> key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex nlHostAddress protocolDirLocalIndex-2";]

I have tried to create text:

   o  The SMIv2 INDEX clause is mapped to the YANG key clause listing
      the columnar objects forming the key of the YANG list.  If the
      same object appears more than once in the INDEX clause, append
      '-<n>' to the object name where '<n>' counts the occurances of the
      object in the INDEX clause, starting from 1.

This would result in

  key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex-1 "
      "nlHostAddress protocolDirLocalIndex-2";

which is slightly different since it modifies all duplicate names
while you left the first untouched. I guess we also need to state that
in this case also multiple leafs with suitable names need to be
generated, right? Hm, this is really a nasty corner case to deal with.

/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: David Reid <[email-masked]>
Date: Tue, 08 Nov 2011 11:45:58 -0500

>       object in the INDEX clause, starting from 1.

That sounds good.

> while you left the first untouched. 

That's fine. Your way does make the text read a little better.

> I guess we also need to state that
> generated, right? 

Yes. I did that in my implementation, but I guess my text didn't say that.

> Hm, this is really a nasty corner case to deal with.

Yep. RMON-2 is the only MIB I know of that does this. But a lot of MIBs 
import from RMON-2, so I think it's worth dealing with.

-David Reid

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Nov 2011 20:22:53 +0100

> That's fine. Your way does make the text read a little better.

While biking home, I realized this is broken. We have to keep the
original leaf untouched because it might be referenced elsewhere. So
we need to introduce additional leafs and we should give them names
that they will never ever conflict with an SMIv2 name. I suggest to
use an underscore character since underscore character are not allowed
in SMIv2 land. Since in many programming languages an underscore is
used to mark an identifier as "somewhat private", we could do this
here as well to mark identifiers created by the translation algorithm
by prefixing them with an underscore. So we would have something like

   key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex "
       "nlHostAddress _protocolDirLocalIndex2";

> Yep. RMON-2 is the only MIB I know of that does this. But a lot of
> MIBs import from RMON-2, so I think it's worth dealing with.

Yes, no doubt, we need to be able to translate all valid SMIv2 MIB
modules of the IETF to valid YANG modules. This is a good test. I
think I will even add the RMON2 case as an example.

/js

---

From: David Reid <[email-masked]>
Date: Tue, 08 Nov 2011 15:12:45 -0500

>        "nlHostAddress _protocolDirLocalIndex2";

Good point.

Why is it necessary to never ever conflict with an SMIv2 name? Is it not
good enough that it does not conflict with any names in that module?

-David Reid

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Nov 2011 12:52:27 +0100

> good enough that it does not conflict with any names in that module?

I think it is generally a good idea to keep namespaces clean. Suppose
someone adds a MIB object protocolDirLocalIndex-2 to RMON2-MIB.
Although perhaps unlikely, we would have a serious problem with our
translation algorithm if it happens.

/js

---

From: David Reid <[email-masked]>
Date: Wed, 09 Nov 2011 09:13:06 -0500

> translation algorithm if it happens.

That makes sense. I like your idea of using a leading underscore.

-David Reid