Subject: RE: [Hubmib] Re: 53rd AToMIB agenda items

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 1 Feb 2002 13:06:33 +0100

Inline

> -----Original Message-----
> From: RJ Atkinson [mailto:[email-masked]]
> Sent: Thursday, January 31, 2002 10:48 PM
> To: Erik Nordmark
> Cc: [email-masked]; AToMMIB Mailing List; Hubmib Mailing List
> Subject: Re: [Hubmib] Re: 53rd AToMIB agenda items
> 
> On Thursday, January 31, 2002, at 09:42 , Erik Nordmark wrote:
> >> the problem with the sonetVTStuff2 and sonetFarEndVTStuff2
> >> is that, as per the conformance clause, you dont implement
> >> it when you dont support VTs. so its optional in the sense of
> >> you only support it when you need it. i see your logic but
> >> i havent seen this logic applied in other cases yet.
> >> it would be both a pity and a problem if you cant advance the
> >> spec because of this; if you dont get the implementation feedback
> >> now you may not get it two years from now either. in that case
> >> the logical conclusion would be to dump the sonetVTStuff2 and
> >> sonetFarEndVTStuff2? lets hope we can get some additional
> >> implementation feedback.
> >
> > Perhaps Bert can comment on the MIB specific issues of how to handle
> > this.
> >
> > In cases where there are some parts of a proposed standard that do not
> > have multiple interoperable implementations where the result has been
> > that those pieces have been lifted out of into a separate specification.
> >
> > Then the core part can be advanced to draft standard while the other
> > specification can be a proposed standard.
> 
This generic approach of splitting out the pieces that seem to not have
been implemented (or at least for which we did not get reports) is
one approach for MIB documents too.

Another approach is to deprecate or even obsolete those objects.
In fact, if we cannot find any implementation feedback, then they
may not be generically usefull and if only one vendor implemented
them, then they seem to belong in an enterprise specific MIB.
So I would then obsolete them.

> I'm wondering if the pain of splitting the stuff into separate documents
> might be avoidable in this case by editing the MIB document to indicate
> which OIDs are mandatory-to-implement and which are optional-to-implement.
> I thought that was one use of the Conformance Clause, but might be 
> confused.
> 
Yes... but the optional to implement would be "generally optional", but
optional in the sens that you would only have to implement objects for
feasture X if you also have feature X on you system. But if feature X 
is only on 1 vendors system, then feature X is probably not an IETF
DS or STD and so the MIB objects for feature X should also not show
up at DS or STD level.

Bert
> Ran
> [email-masked]

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

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 1 Feb 2002 13:06:33 +0100

Inline

Bert