Subject: [ifmib] Restart ifmib WG?

From: Thomas Narten <[email-masked]>
Date: Wed, 02 Oct 2002 13:34:14 -0400

The ifmib WG still exists on paper, but hasn't been active for some
time.

There are still (IMO) some important work items that would be good to
get done. For example:

 - advance IF-MIB to full std
 - advance inverted stack table mib to DS

There might be some more possible items, but the above ones are
critical in the sense that there are other documents that can't
advance until the above takes place.

Who here thinks the above are important to do? And just as important,
are their folk here who would be willing to contribute cycles reviewing
drafts, editing drafts, etc.?

Are there other work items that should be considered?

Thomas
_______________________________________________
ifmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ifmib

---

From: "Dave Thaler" <[email-masked]>
Date: Wed, 2 Oct 2002 15:49:30 -0700

> Are there other work items that should be considered?

RFC 2667 defines the IPv4 Tunnel MIB.
It was generally agreed that a separate document would eventually
be done for a tunnel over IPv6.

If the decision is made to restart the ifmib WG, then I
would like this to be considered as a work item.
I am willing to spend cycles on it, especially since I
expect it should be quite straightforward.

-Dave

---

From: Andy Bierman <[email-masked]>
Date: Mon, 07 Oct 2002 11:02:17 -0700

At 09:56 AM 10/7/2002 -0700, C. M. Heard wrote:
>[ Followups to [email-masked] please ]
>>....
>
>> optional enhancements:
>> 
>>  - ifMtu needs a read-write version
>> 
>> the following objects may be available in a different MIB
>> for some media types:
>> 
>>  - ifSpeed needs a read-write version
>>  - ifHighSpeed needs a read-write version
>
>If you add these new objects to the IF-MIB then it will have
>to recycle at proposed.  That would prevent any MIB modules
>that depend on the IF-MIB in a normative way -- and there
>are plenty of those -- from advancing past proposed standard.
>It might, therefore, be better to put these things into a
>supplemental IF MIB module.

I agree any new objects should be in a separate module in
a separate RFC

>On Mon, 7 Oct 2002, Romascanu, Dan (Dan) wrote:
>> Hmmm. What happens now with those MIBs who already defined
>> their own objects, like the MAU MIB? It is very nice to fix
>> this problem now, in the 21st century, but we create a
>> compatibility problem, or at least a set of questions that
>> need to be asked. (will ifMauSpeed be deprecated, if not which
>> one takes precedence when their values are not consistent, etc.)
>
>If the "extras" are defined in a supplemental IF MIB module,
>then one way to resolve these questions might be to require
>that applicability of the objects in the supplemental IF MIB be
>spelled out by each media-specific MIB module, in analogy with
>the requirements in Section 4 of RFC 2863.  The default, in the
>absence of any guidance in the media-specific MIB module, would
>be that the objects do not apply.  That would leave the meaning
>of existing media-specific MIBs that provide their own objects
>unchanged.

I don't think the MAU-MIB objects are widely implemented.
Mike's proposal seems to address the precedence issue.

>Mike

Andy

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 9 Oct 2002 09:50:45 -0700 (PDT)

Juergen Schoenwaelder wrote:

> >>>>> C M Heard writes:
> 
> C> If you add these new objects to the IF-MIB then it will have to
> C> recycle at proposed.  That would prevent any MIB modules that
> C> depend on the IF-MIB in a normative way -- and there are plenty of
> C> those -- from advancing past proposed standard.  It might,
> C> therefore, be better to put these things into a supplemental IF MIB
> C> module.
> 
> While I understand the logic here, I believe that for many people
> outside of the IETF, this approach is just confusing. Most people I
> have seen simply want the latest IF-MIB and not an ever growing set of
> IF-MIBs (due to the way we apply the IETF standards process rules).

[ ... ]

> >>>>> C M Heard writes:
> 
> Mike> Are you suggesting that we should treat MIB modules as BCPs
> Mike> instead of putting them on the standards track?
> 
> No. I think we should allow the publication of RFCs that update MIB
> modules published in other RFCs. An official repository, probably
> maintained by IANA, must be established that holds the latest merged
> versions of the MIB modules. Once updates have progressed and reached
> the same status of the original MIB document, things might be merged
> into a subsequent RFC which describes the whole thing in one piece.
> 
> I think we do exactly this with other protocols. Why should this not
> work with MIBs as well? I think the RMON update to support high
> capacity counters is a good example that there are cases where it is
> not really practicable to put all changes in separate modules.

The point is well-taken, but I think that we'd still need to publish
two IF-MIB documents.  One would be an RFC containing the IF-MIB 
module with the corrections pointed out by Andy but without any
new objects.  It would become the Internet Standard IF-MIB RFC.  The
second document would be an incremental update with the new objects.
It would become a proposed standard RFC.  The on-line version of the
IF-MIB would contain the merged version with the new objects.  Note
that its conformance statements would have to be written to be 100%
backward compatible with the Standard IF-MIB.  In particular, the
ifCompliance3 compliance statements (assuming that it remains as
is in the Standard IF-MIB) would, in the merged MIB module, remain
in place with its STATUS current and with its meaning unchanged.

Mike