Re: EOS Row Operations (and other documents)

[Michael Thatcher <thatcher@redback.com>]

So why not use Agent Capabilities.  Itsn't that the purpose - One's
implementation of an object can be documented that it supports a subset
of a particular definition.

miket

Glenn Waters wrote:

>
>
> The existing RowStatus TC has createAndWait among its acceptable
> values. If an object is defined with RowStatus then it should accept
> all the acceptable RowStatus values. createAndWait is not among the
> desirable values that we would like in a row status object thus we
> must create a "NewRowStatus" TC (or whatever we call it). The
> NewRowStatus would be the same as the existing RowStatus minus the
> undesirable parts.
>
> Hope that helps.
>
> Cheers, /gww
>
> > -----Original Message-----
> > From: Joel M. Halpern [mailto:joel@longsys.com]
> > Sent: Monday, March 26, 2001 12:57
> > To: EOS WG (E-mail)
> > Subject: Re: EOS Row Operations (and other documents)
> >
> > I listened to the discussion at the working group, and then read
> Lauren's
> > description, and I am confused.  What is the behavior / need / ...
> that
> > this work item is addressing that is not addressed just by people
> using
> > creatAndGo?
> > Yours,
> > Joel M. Halpern
> >
> > At 08:08 AM 3/24/01 -0800, Lauren Heintz wrote:
> > >    - A new RowStatusLite TC (actual name yet to be determined)
> > >      This TC will represent an evolvement from the current
> > >      RowStatus TC.  RSLite will not include a createAndWait
> status,
> > >      and will require implmentations to support other extended
> features
> > >      such as the SetRow PDU.  I personally wonder if the row
> timeout
> > >      requirement for NotInService states is still required,
> because I
> > >      believe that overly complicates configuration chores (I think
> NIS
> > >      should be a valid, persistent conceptual config state).
> >