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

Re: RowStatus questions

For our enterprise MIBs we use #4.  #4 is also a good way to specify which
items besides the table keys are required at row creation.  Keep in mind
that restricting RowStatus to "one-shot" mode, in principle, should only be
done if the protocol can handle the row size.  However, I am not sure there
is a toolset out there that looks at the compliance statement.

Sidney Antommarchi
VXi - Systems Engineering

                    Wes Hardaker                                                                                    
                    <wes@hardaker        To:     eos@ops.ietf.org                                                   
                    s.net>               cc:                                                                        
                    Sent by:             Subject:     RowStatus questions                                           
                    11:40 PM                                                                                        

Ok, so lets say you're writing a MIB today (many of us are).  Everyone
supposedly hates RowStatus, but the primary reason is the
create-and-wait state.

So, if you were writing a (standards-based) MIB what would you do
given todays choices:

1) use RowStatus as is, since it's still the currently accepted method.
2) Make something up for the MIB (ick).
3) use new not-yet standardized ideas (eos-rowops, being one example).
   [this isn't really an option of course, since I expect my draft to
    go to proposed before the eos is done debating this issue, and I
    can't wait (let alone wait for new deployment of protocol code)]
4) use RowStatus but in the compliance statements specify that the
   createAndWait enum value isn't required.
5) ???

"The trouble with having an open mind, of course, is that people will
 insist on coming along and trying to put things in it."   -- Terry