[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: EOS Row Operations (and other documents)
I checked rfc1903/2579, and it's permissable
for an implementation NOT to respond to createAndWait
and/or createAndGo. I know it's at least common
practice to forbid one and/or the other or both.
To understand how a replacement TC would
behave (or whether it's even needed), seems
we first need to know how the new proposed
SetRow PDU would behave under various existing
conditions when tables use the current RowStatus
I think depending on how SetRow behaves, it may
be possible to avoid defining a new TC altogether
and still allow interoperability with existing
RowStatus implementations (and at least that
should be the design goal I would think).
- Does SetRow need to work with existing tables that
use RowStatus? If so, is the RowStatus object transparent
to the SetRow PDU or must the SetRow PDU also contain a
RowStatus value for that column (just like any other column)?
Implications: If RowStatus is not transparent (i.e.
must be specified), then SetRow semantics may be limited
when directed against existing tables using RowStatus.
For example, if createAndWait is supported in a table
but not createAndGo, then setRow can at most create only
NotInService rows if a RowStatus value must be
provided in the SetRow PDU. Another SET would have to
follow the SetRow and would contain a RowStatus of
active to complete row activation (or the SetRow could
instead contain "active" to indicate the agent should do
an implicit createAndWait before activating the row).
- Will the SetRow PDU normally create new rows (where one doesn't
exist) or modify/replace a row (if one exists)? Or must the
operation be explicit so that actions such as "replace-but-don't-
create" can be achieved? If the operation needs to be explicit,
then does the SetRow PDU need an integral "operation" field or do
we instead require a companion RowStatus-family (old or new) TC in
the table whose value must be provided in the PDU?
- Can SetRow be used to delete a row? How? Does
it specify a "destroy" value in the appropriate column
(and therefore need a companion RowStatus-family TC in
the table) -- or maybe we simply stuff NoSuchInstance
in every column in the SetRow PDU to indicate a delete op
is in progress. Or do we rely on old fashioned SET PDUs,
and if you want your tables to support row destruction,
just use the old RowStatus and limit the states you accept
- Does SetRow operate on rows not using RowStatus at all
but whose objects are read-create? If so, this may imply
a new RowStatus TC is not REQUIRED to support a SetRow PDU,
and that any new RowStatus TC that we design is more for the
purpose of resolving unrelated things we may not like about
the current RowStatus behavior (i.e. the proposed relaxation
of the NotInService timeout rules that I would like to see
> 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:firstname.lastname@example.org]
> > 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
> > description, and I am confused. What is the behavior / need / ...
> > this work item is addressing that is not addressed just by people
> > 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
> > > and will require implmentations to support other extended
> > > such as the SetRow PDU. I personally wonder if the row
> > > requirement for NotInService states is still required,
> because I
> > > believe that overly complicates configuration chores (I think
> > > should be a valid, persistent conceptual config state).