Subject: [netmod] iana-if-type vs. IANAifType-MIB

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Apr 2011 20:03:49 -0700

Hi,

IMO the module iana-if-type.yang is demonstrating a problem
with the SMIv2 to YANG mapping.

The custom version of this module is not really any different than
the auto-generated module.  I do not really like changing the names
of SMIv2 definitions if they are not being redesigned in YANG.

I suspect this is done so ietf-interface.yang can import a real module.
Does this mean that any new YANG module that
references SMIv2 definitions is going to create 1-off custom versions
of the imported SMIv2 modules?  Does this mean there will be an ad-hoc
collection of RFCs that contain hand-converted versions of SMIv2 modules?

Is there some way to just have an IANA registry of YANG modules for converted
SMIv2 modules?  That way IANAifType-MIB can be imported
in a new YANG module, even though there is no actual RFC containing
the converted YANG module.  The new module RFC would cite the original
RFCs (plus the SMIv2-to-YANG RFC, plus the IANA registry), and there
will no need to republish any SMIv2 modules.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 23 Apr 2011 07:34:57 +0200

> collection of RFCs that contain hand-converted versions of SMIv2 modules?

The module was hand crafted in order to make enum descriptions and
references machine readable and to capture the fact that some enums
are deprecated. Perhaps we need to add explicit text about this to
the introduction.
 
> Is there some way to just have an IANA registry of YANG modules for
> converted SMIv2 modules?  That way IANAifType-MIB can be imported in
> a new YANG module, even though there is no actual RFC containing the
> converted YANG module.  The new module RFC would cite the original

I think this was briefly discussed some time ago but the resolution
was deferred until we get such a dependency. As explained above, the
creation of a YANG version of the interface type registry was not
driven by an attempt to avoid such a dependency.

/js (as contributor)

-- 
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: Andy Bierman <[email-masked]>
Date: Sat, 23 Apr 2011 02:30:45 -0700

> driven by an attempt to avoid such a dependency.

So we will have some YANG modules, written by hand, that import iana-if-type.yang,
and other YANG modules, generated from the SMIv2 to YANG algorithm,
that imports IANAIfType-MIB.yang?  Or do you have a hack in your
draft that says all imports of IANAIfType-MIB get changed to
the module name iana-if-type instead?   What a mess.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 23 Apr 2011 13:00:22 +0200

On Sat, Apr 23, 2011 at 02:30:45AM -0700, Andy Bierman wrote:
 
> So we will have some YANG modules, written by hand, that import
> iana-if-type.yang, and other YANG modules, generated from the SMIv2
> to YANG algorithm, that imports IANAIfType-MIB.yang?  Or do you have
> a hack in your draft that says all imports of IANAIfType-MIB get
> changed to the module name iana-if-type instead?  What a mess.

Since both enumerations are maintained by IANA from the same registry,
there should not be any mess. And a grep of IANAifType-MIB through all
IETF MIB modules says that the scope of the so called "mess" is rather
limited (APPN-MIB, DIAL-CONTROL-MIB, DOCS-IF-MIB, IF-MIB, ISDN-MIB).

If people feel strongly that the SMIv2 to YANG translation should
special case the handling of IANAifType, I could change the I-D and my
implementation.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 23 Apr 2011 10:23:33 -0700

> limited (APPN-MIB, DIAL-CONTROL-MIB, DOCS-IF-MIB, IF-MIB, ISDN-MIB).

IMO, this is a problem for any converted module that uses the IF-MIB,
even by reference via ifIndex INDEX (a module does not need to import
IANAifType-MIB to reference it in DESCRIPTION clauses).  Vendor MIB
modules can be affected as well. Did you search for 'ifType' in DESCRIPTION clauses?

This introduces a new module with a new typedef (iana-if-type instead
of IANAifType).  Why?  What value does this have?
How will old/auto-generated modules integrate with new YANG modules
that need to build on the old definitions (instead of throw everything
out and start over)?

> special case the handling of IANAifType, I could change the I-D and my

I prefer no special cases.  There is no reason to change any descriptors
in ad-hoc fashion.

The standard mapping is special-casing this module by creating a clone
with almost the same contents, and a different name.  Neither YANG or SMIv2
has a mechanism for deprecating enum values within a 'current' typedef.
Just leave the old values there.  What does it break?

The problem is that YANG is not being used correctly.
This is not a new module, just a new revision of an existing module.
There is no need to create a clone, change the name of the module or the definitions.

If you really want an updated IANA-ifType-MIB:
   - Rename the module iana-if-type to be IANAifType-MIB.
   - Rename the typedef iana-if-type to be IANAifType.
   - Use the same XML namespace for all versions of this module, just change the revision date.
   - Import-by-revision can be used if it really matters to the data modeler.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 23 Apr 2011 20:59:08 +0200

>   - Import-by-revision can be used if it really matters to the data modeler.

Sorry, I can't follow your arguments nor do I see where there is a
problem.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 23 Apr 2011 13:19:13 -0700

> Sorry, I can't follow your arguments nor do I see where there is a

There is an IANAifType already.
I do not understand why NETCONF/YANG needs to replace this widely used TC
with a different typedef called iana-if-type. This will only cause
confusion and add no value at all.  That is one problem.

I think all the descriptors from SMIv2 should map directly to YANG identifiers,
without any modification. This new module does not follow that rule.
That is the other problem.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 24 Apr 2011 10:26:12 +0200

> confusion and add no value at all.  That is one problem.

There is added value since the YANG version adds enum specific
descriptions, references, and status statements. You might argue that
this is not worth the effort, but that is than an opinion not a
problem.
 
> I think all the descriptors from SMIv2 should map directly to YANG
> identifiers, without any modification.

I do not understand what this rule means in this context.

> This new module does not follow that rule.  That is the other
> problem.

It might help if you can point out where the enumeration is different
(other than the added enum specific descriptions, references, and
status statements) since that might be a bug.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sun, 24 Apr 2011 04:23:40 -0700

> I do not understand what this rule means in this context.

IANAifType has changed to iana-if-type.  Why?

> status statements) since that might be a bug.

What problem are you solving by renaming the module and the typedef?
I don't care that the meta-stmts surrounding the enums are slightly better.
You can do that without changing the name of the module or the typedef.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Apr 2011 21:16:11 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> Neither YANG or SMIv2

YANG has such a mechanism.

> The problem is that YANG is not being used correctly.

What does "not being used correctly" mean?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 25 Apr 2011 12:35:43 -0700

On 04/25/2011 12:16 PM, Martin Bjorklund wrote:
> Andy Bierman<[email-masked]>  wrote:
>> Neither YANG or SMIv2

Instead of revising an existing module, you are cloning
a well-known SMIv2 module as if it were a new module.

I don't really have time to work on this document anymore,
so do whatever you want.

Andy