[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Place Holders
At 12:10 AM 7/3/2003, Romascanu, Dan (Dan) wrote:
>Why should we leave them in? I understand that this is legal SMI, but this smells like documented OID sparseness. One of the MIBs I authored lately received a comment from the MIB Doctor concerning OID sparseness. That one was caused as it often happens because of the evolution of the MIB, some OIDs being removed in the process, because the WG decided not to implement the objects. I fail to see the difference. If OID sparseness is a bad thing, we should avoid creating such cases by reserving OIDs for 'future use'.
Maybe the WG is going to implement objects under the placeholder
OID later. In any case, this is a totally trivial problem.
It doesn't matter either way. This has no impact on implementation.
This is just MIB style, about as important as the number of
spaces you should indent before starting a comment.
>Thanks,
>
>Dan
>
Andy
>> -----Original Message-----
>> From: Andy Bierman [mailto:abierman@cisco.com]
>> Sent: 02 July, 2003 8:34 PM
>> To: Robert Moore
>> Cc: Harrington, David; Romascanu, Dan (Dan); mibs@ops.ietf.org
>> Subject: RE: Place Holders
>>
>>
>> At 09:20 AM 7/2/2003, Robert Moore wrote:
>>
>>
>>
>>
>> I agree with Bob. There are no interoperability issues
>> created by defining OID nodes to be used later. This is
>> legal SMI with no impact on implementations. What problem
>> would be solved by removing these OIDs?
>>
>> Andy
>>
>>
>>
>> >Dave / Dan, ,
>> >
>> >I'm not seeing the problem y'all are seeing here. We're not
>> talking about
>> >OBJECT-GROUPs in the conformance sense. They're just
>> setting aside empty
>> >OID subtrees, for possible use later. I don't see why the
>> current document
>> >would be prevented from advancing all the way to Full
>> Standard with these
>> >placeholders in it: the only requirement is that there be independent
>> >implementations of all the objects and notifications that
>> *are* there.
>> >Later, separate documents (with separate MIB modules) could
>> be introduced,
>> >to define objects to populate these subtrees. These new
>> modules would just
>> >IMPORT the subtree roots, and go from there.
>> >
>> >This approach *might* be distasteful from an IANA
>> perspective (or it might
>> >not be -- I don't know). But I don't see anything wrong
>> with it from
>> >either the SMI or IETF-process side.
>> >
>> >Regards,
>> >Bob
>> >
>> >Bob Moore
>> >WebSphere Advanced Design and Technology
>> >WebSphere Platform System House
>> >IBM Software Group
>> >+1-919-254-4436
>> >remoore@us.ibm.com
>> >
>> >
>> >
>> >
>>
>>
>> > "Harrington,
>>
>>
>> > David" To:
>> "Romascanu, Dan (Dan)" <dromasca@avaya.com>,
>> <mibs@ops.ietf.org>
>> > <dbh@enterasys.co cc:
>>
>>
>> > m> Subject: RE:
>> Place Holders
>>
>> > Sent by:
>>
>>
>> > owner-mibs@ops.ie
>>
>>
>> > tf.org
>>
>>
>> >
>>
>>
>> >
>>
>>
>> > 07/02/2003 11:54
>>
>>
>> > AM
>>
>>
>> >
>>
>>
>> >
>>
>>
>> >
>> >
>> >
>> >
>> >Hi,
>> >
>> >Assuming this is being put forth for standardization, I don't see how
>> >the mib module will be able to have multiple independent
>> >implementations, or how it can be shown that all the
>> features have been
>> >implemented, if they are just placeholders.
>> >
>> >There may be a real disadvatnage for the WG to use placeholders. The
>> >objects that fall under these placeholders are apparently
>> not necessary
>> >to the "base" standard. When new work is added under the
>> placeholders,
>> >they will probably need to reopen the document and recycle
>> at proposed
>> >to add the new objects. If developed in separate mib modules, the
>> >original work will not need to recycle at proposed when the
>> new work is
>> >added.
>> >
>> >David Harrington
>> >dbh@enterasys.com
>> >co-chair, IETF SNMPv3 WG
>> >
>> >-----Original Message-----
>> >From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
>> >Sent: Wednesday, July 02, 2003 9:29 AM
>> >To: mibs@ops.ietf.org
>> >Subject: Place Holders
>> >
>> >
>> >The SIP MIB which just published a new version
>> draft-ietf-sip-mib-06.txt
>> >has what can be considered a nit which I am trying to
>> understand whether
>> >I should push back. The authors have reserved four object groups
>> >(sipRedirCfg, sipRedirStats, sipRegCfg, sipRegStats) but
>> left them empty
>> >for 'future use'. I so not think that this is explicitly
>> forbidden, but
>> >it seems like a dubious practice, which can create potential holes if
>> >other groups are defined in the coming versions, without all the four
>> >groups being used (yet).
>> >Any opinions?
>> >Thanks,
>> >Dan
>>
>>