Subject: RE: [newtrk] Recycling at Proposed seems to document best current practice in the MIB module space

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 23 Jan 2006 14:47:05 +0100

I think the message is that "yep, it may be generic, but specifically
for MIB documents (our field of expertise) we (MIB Doctors) have found
this to be the case."

Bert

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Brian E Carpenter
> Sent: Monday, January 23, 2006 13:50
> To: C. M. Heard
> Cc: [email-masked]
> Subject: Re: [newtrk] Recycling at Proposed seems to document best
> current practice in the MIB module space
> 
> 
> It isn't quite clear to me whether the argument is that MIBs
> are a special case. The same issues (the need to invest
> a lot of detailed effort and to remove features) apply to
> all types of technical specification at the PS to DS transition.
> 
>     Brian
> 
> C. M. Heard wrote:
> > There was recently a discussion on the MIB Doctors list that
> > should be of interest to this WG, unless it is too exhausted
> > to continue working on its charter.  The discussion can be
> > viewed here:
> > 
> > http://ops.ietf.org/lists/mreview/mreview.2005/threads.html#00456
> > 
> > and the conclusion that I have quoted in the subject line is
> > accessible here:
> > 
> > http://ops.ietf.org/lists/mreview/mreview.2005/threads.html#00467
> > 
> > Happy reading.
> > 
> > //cmh
> > 
> > .
> > newtrk 
> resources:_____________________________________________________
> > web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
> > mhonarc archive: 
http://darkwing.uoregon.edu/~llynch/newtrk/index.html

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 26 Jan 2006 18:30:43 +0000

I wonder whether the reason that MIBs appear to have different 
characteristics is that the concept of interoperability applies somewhat 
differently to MIBs: MIBs specify the interpretation to be put on 
various OIDs and what data should be expected in association with such 
an OID.  The encoding on the wire is self-describing, and if the ASN.1 
and the SNMP protocol are working correctly, exactly what the MIB tree 
at the agent looks like doesn't stop a manager and an agent exchanging 
bits on the wire - a manager can usually display the MIB tree even if it 
doesn't have fancy graphics and mappings to human readable names.  Two 
agents implementing a given MIB never exchange data directly (unless 
things have changed since I was more involved with MIBs), so 
'interoperability' applies at a higher level: the manager expects a 
particular set of OIDs with particular data types and has some sort of 
application which is used to display the information in a more 
comprehensible way.

Once the MIB is defined and the mappings set up, there is very little to 
check in terms of interoperability, and it isn't about bits on the wire 
but about what OIDs are implemented and how..

If the MIB definition is wrong or has to be improved, this generally has 
to be done by adding new OIDs - modification is generally going to be a 
problem.  I think what this says is that the interoperability criteria 
need to be altered for MIBs (how is this handled at the moment?) and the 
idea of removing unused capabilities etc really amounts to editorial 
qualifications on the data collection rather than changes to the OIDs.  
I am not really a MIB expert so this may be wrong...

Regards,
Elwyn

.

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 26 Jan 2006 23:31:32 -0800 (PST)

On Thu, 26 Jan 2006, Elwyn Davies wrote:
> characteristics is that the concept of interoperability applies
> somewhat differently to MIBs: [...] the manager expects a
> particular set of OIDs with particular data types and has some
> sort of application which is used to display the information in
> a more comprehensible way.

True, and because of this there are special rules for checking
interoperability of implementations for advancement on the standards
track.  See RFC 2438.

However, I don't think that there is much difference between MIB
modules and other specs when it comes to the reasons why people
generally don't bother to advance them beyond Proposed Standard.

> Once the MIB is defined and the mappings set up, there is very
> little to check in terms of interoperability, and it isn't about
> bits on the wire but about what OIDs are implemented and how..
> 
> If the MIB definition is wrong or has to be improved, this
> generally has to be done by adding new OIDs - modification is
> generally going to be a problem.  I think what this says is that
> the interoperability criteria need to be altered for MIBs (how
> is this handled at the moment?) and the idea of removing unused
> capabilities etc really amounts to editorial qualifications on
> the data collection rather than changes to the OIDs.  I am not
> really a MIB expert so this may be wrong...

No, you are right on target.  Current doctrine is that if a MIB
object does not exist in at least two implementations, then in order
to advance the MIB module that contains it one must retire the
object by changing its status from 'current' to 'deprecated' or
'obsolete'.  One must also issue updated compliance statements that
don't require that the retired object be implemented.

//cmh

.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 27 Jan 2006 10:03:22 +0200 (EET)

On Thu, 26 Jan 2006, C. M. Heard wrote:
...
> generally don't bother to advance them beyond Proposed Standard.

For what it's worth, there may be a couple of reasons behind that:

  1) for vendor FOO, it's too big an effort to monitor (too closely)
     all the WGs working on all the specifications that vendor FOO
     implements. This requires too much effort compared to the benefit.

  2) Participating in an interop/implementation report doesn't bring
     much benefit if the solution has already been shipped (i.e.,
     getting an RFC number doesn't give enough benefit and/or vendor
     FOO knows that there are other implementations as well and
     "others" could just do the report, saving them from the pain.)

     I'd assume most vendors already have sufficient
     interop/implementation information internally (they must have
     tested the products against other common products in the field,
     and know which features are implemented), but participating in
     public dissemination of that information might not be worth
     the effort.

As for 1), one way to possibly fix this is to make announce these 
change (proposals) in just one IETF-wide place, so folks wouldn't need 
to monitor all the mailing list traffic.  I'm rather stumped by 2) 
though.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html