RE: Last Call: 'Remote Network Monitoring MIB Extensions for Switch Networks Version 1.0' (RFC 2613) to Draft

["C. M. Heard" <heard@pobox.com>]

On Wed, 16 Apr 2003, Wijnen, Bert (Bert) wrote:
> Mike... does Andy's comment make sense w.r.t. RFC2021?

If you mean this comment:

Andy> It could be an important issue, but it's extremely unlikely
Andy> the imported TCs will change, and the registration OIDs
Andy> cannot change.

then the answer is yes, I do agree; in fact I said as much in my
message:

Mike> [ ... ] the imported items are either textual conventions
Mike> that are not likely to be obsoleted or object identifier
Mike> values that can't change at all.

There is one caveat I'd like to mention.  One of TCs in question
(LastCreateTime) has a bug in it:  it uses TimeStamp as a base type,
which the SMIv2 no longer permits (ControlString has a similar bug).
Fixing this is a just language technicality, however, and won't have
any impact on existing implementations.

> If we accept that, then I could try to justify a "variance procedure"
> as described in RFC2026. But that probably also means that we need
> to document (a one or two page RFC) as to why we do so.
> 
> There are a few real solutions of course, but they all require more work
> 
> a. more rigorous, probably best solution:
>    - We extract the OID assignments and the TCs from 2021 and get them
>      in a separate doc that we do PS and in 6 months ds and in another
>      6 months STD.
>    - we then need to to update 2613 to import from new doc (but we 
>      have 6 months for that). We can then at same time make updates for
>      new MIB Boilerplate and sec considerations, other administrativia

It would certainly be possible to get that document advanced to DS
fairly quickly, since all of the existing RMON2-MIB implementations
would count as implementations of these TCs.  However, if an updated
RMON2-MIB were to be published concurrently, it should be possible
to get that to DS almost as fast.  So from that perspective I don't
see a big advantage in separating the TCs out.  It would be kind of
a hassle for the RMON2-MIB itself since it would still have to keep
the original definitions, and if it were to IMPORT the
(authoritative) versions of the TCs to use in its object definitions
it would have to use the modulename.TCname notation to disambiguate
the references.  That's legal but not often done, and it's probably
a good idea to avoid relying on rarely-used SMIv2 features.

> b. simpler, maybe not the ideal solution:
>    - We could update 2613 to change TCs to base datatypes, or specify
>      the same TCs with different name). We could create the OID assigments
>      directly instead of importing.
>      We can then at same time make updates for new MIB Boilerplate and
>      sec considerations, other administrativia

Ugh.

> c. Wait till 2021 gets advanced to DS (may take a long time).

It seems to me that this would not take much longer than (a).

> d. variance procedure
>    - as described above. probably means writing a 1-2 page RFC.
> 
> In any event... it seems a lot of hassle.

I would be inclined to say that (c) or (d) is the most straighforward.

For the record, the TCs in RFC 2021 are ZeroBasedCounter32,
LastCreateTime, TimeFilter, DataSource, and ControlString;  of
these, all except ControlString are used in other standards-track
MIB modules.  Here is the list of who uses what, courtesy of the RFC
Editor's content search feature:

ZeroBasedCounter32:
   RFC 2021 Remote Network Monitoring Management Information Base
   Version 2 using SMIv2 S. Waldbusser
   RFC 2605 Directory Server Monitoring MIB G. Mansfield, S. Kille
   RFC 3273 Remote Network Monitoring Management Information Base
   for High Capacity Networks S. Waldbusser
   RFC 3287 Remote Monitoring MIB Extensions for Differentiated
   Services A. Bierman
   RFC 3295 Definitions of Managed Objects for the General Switch
   Management Protocol (GSMP) H. Sjostrand, J. Buerkle, B.
   Srinivasan

LastCreateTime:
   RFC 2021 Remote Network Monitoring Management Information Base
   Version 2 using SMIv2 S. Waldbusser
   RFC 2613 Remote Network Monitoring MIB Extensions for Switched
   Networks Version 1.0 R. Waterman, B. Lahaye, D. Romascanu, S.
   Waldbusser
   RFC 3287 Remote Monitoring MIB Extensions for Differentiated
   Services A. Bierman

TimeFilter:
   RFC 2021 Remote Network Monitoring Management Information Base
   Version 2 using SMIv2 S. Waldbusser
   RFC 2674 Definitions of Managed Objects for Bridges with Traffic
   Classes, Multicast Filtering and Virtual LAN Extensions E. Bell,
   A. Smith, P. Langille, A. Rijhsinghani, K. McCloghrie
   RFC 2720 Traffic Flow Measurement: Meter MIB N. Brownlee
   RFC 2922 Physical Topology MIB A. Bierman, K. Jones
   RFC 3287 Remote Monitoring MIB Extensions for Differentiated
   Services A. Bierman

DataSource:
   RFC 2021 Remote Network Monitoring Management Information Base
   Version 2 using SMIv2 S. Waldbusser
   RFC 2613 Remote Network Monitoring MIB Extensions for Switched
   Networks Version 1.0 R. Waterman, B. Lahaye, D. Romascanu, S.
   Waldbusser
   RFC 3287 Remote Monitoring MIB Extensions for Differentiated
   Services A. Bierman

ControlString:
   RFC 2021 Remote Network Monitoring Management Information Base
   Version 2 using SMIv2 S. Waldbusser

Note that if the TCs are moved to an external document, then all of
the "consumer" modules will need to change their IMPORTS statement
when advancing along the standards track.  That's not hard work,
but it is one more thing to remember to do, and one more reason
to disfavor the separate document aproach.

//cmh