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

Re: EOS Row Operations (and other documents)




>>>>> Lauren Heintz writes:

Lauren> Here are some ititial impressions on the proposed row
Lauren> operations document content (just to get things rolling):

[...]

Lauren>    - A new RowStatusLite TC (actual name yet to be determined)
Lauren> This TC will represent an evolvement from the current
Lauren> RowStatus TC.  RSLite will not include a createAndWait status,
Lauren> and will require implmentations to support other extended
Lauren> features such as the SetRow PDU.  I personally wonder if the
Lauren> row timeout requirement for NotInService states is still
Lauren> required, because I believe that overly complicates
Lauren> configuration chores (I think NIS should be a valid,
Lauren> persistent conceptual config state).

I believe that object^H^H^H^H^H^Hrow creation and deletion should be
supported natively by the base protocol. The argument that row
creation/deletion is a MIB object issue is IMHO not valid. And several
years of RowStatus experience, which tries to address this problem by
introducing more MIB objects, kind of proves to me that it does not
work very well. The COPS-PR install thing seems to handle row creation
much better as it defines the order of the values and even allows to
return row type specific failure codes. We need at least the same
functionality.

In other words: We do not need another RowStatusLite TC. Instead, we
should support row creation/deletion natively in the protocol. (The
SMIv2 has the read-create access which should be sufficient to
determine where row creation/deletion makes sense. And SMIng can
take care of things like row type specific failure codes.)

/js