RE: RowStatus questions

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Title: RE: RowStatus questions

I think that in the Diffserv MIB, all the rows (in whichever table) can be

fit in a 474 byte backet. So to me it seems that for that MIB Module

all is OK.

 

For MIB Modules that have rows and the packet size would go up to

1482 (or whatever the number is that we currently have for ethernet)

I would still be supporting to do createAndGo only.

 

Not sure I know of any agents that would limit on the number of varBinds.

Are you aware of any? If so, then I guess those cannot be

used to support these type of MIB Modules (personal opinion).

Bert

-----Original Message-----
From: Harrington, David [mailto:dbh@enterasys.com]
Sent: Wednesday, May 15, 2002 6:23 PM
To: 'Harrie Hazewinkel'; Wes Hardaker; eos@ops.ietf.org
Subject: RE: RowStatus questions

MIBs that contain this type of advice should also include advice about making sure the agent supports enough varbinds to accommodate a createAndGo for that row.

dbh

> -----Original Message-----
> From: Harrie Hazewinkel [mailto:harrie@jumpy.it]
> Sent: Friday, May 10, 2002 1:00 PM
> To: Wes Hardaker; eos@ops.ietf.org
> Subject: Re: RowStatus questions
>
>
> Hi Wes,
>
> Not speaking of any preference, but number 4 is acceptable
> from an IETF perspective in my opinion. For instance, the
> DIFFSERV-MIB has this in its compliance statements:
>
> >    OBJECT diffServDataPathStatus
> >    SYNTAX RowStatus { active(1) }
> >    WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
> >    DESCRIPTION
> >       "Support for createAndWait and notInService is not required."
>
> And this was a compromise after the MIB editor did not really
> want to have the full implementation of a RowStatus.
>
> Harrie
>
>
> --On Thursday, May 9, 2002 9:40 PM -0700 Wes Hardaker
> <wes@hardakers.net>
> wrote:
>
> >
> > 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
> > Pratchett
> >
> > 
>