[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Place Holders

Eventhough there is no interoperability problems with this approach, 

In my opinion this is a IETF specific decision over a trivial case (more
formalism than real meat), and I  believe it would make more sense
describing in the RFC document the future work as a guideline in a text
section rather than in the mib definitions section  (Author being more
explicit about the intended mib extension )


-----Original Message-----
From: Andy Bierman [mailto:abierman@cisco.com] 
Sent: Wednesday, July 02, 2003 11:34 AM
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?


>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.
>Bob Moore
>WebSphere Advanced Design and Technology
>WebSphere Platform System House
>IBM Software Group

>                      "Harrington,

>                      David"                   To:       "Romascanu,
Dan (Dan)" <dromasca@avaya.com>, <mibs@ops.ietf.org>              
>                      <dbh@enterasys.co        cc:

>                      m>                       Subject:  RE: Place
>                      Sent by:

>                      owner-mibs@ops.ie

>                      tf.org



>                      07/02/2003 11:54

>                      AM



>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

>David Harrington
>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,