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

Re: EOS Row Operations (and other documents)

Hi -

> Message-ID: <3AC519AE.F745075E@cisco.com>
> Date: Fri, 30 Mar 2001 15:41:34 -0800
> From: Lauren Heintz <lheintz@cisco.com>
> To: Robert Story <rstory@freesnmp.com>
> CC: "EOS WG (E-mail)" <eos@ops.ietf.org>
> Subject: Re: EOS Row Operations (and other documents)
> References: <3ABCC682.C1730E8C@cisco.com>
> 	 <p04330100b6ea86b90fd0@[]> <3AC4F4B5.D3C25EAD@cisco.com> <p0433010bb6eaafecbdc7@[]>
> I like the last choice (before other) because, as long
> as we're wrapping the PDU in the old SET, why not wrap it
> in the old AgentX TestSet as well (i.e. stuff an
> operator in the RESERVED field).  

Like it or not, this WOULD be a protocol change.
At the very least, one would need to add elements
of procedure that describe what would be done with
these bits.

>                                   Thusly, we achieve
> full row mgmt at the protocol level and get rid of
> the need for RowStatus (and don't force re-spins
> of either rfc1905 or AgentX???).

It sounds like a change to both.  Protocol is more
that just syntax.

>                                   Also, step-wise evolution
> of legacy systems (by simple PDU translation) is possible
> on a subagent by subagent basis,

What would this mean for someone wanting to claim conformance?

I think it's important with any of these proposals to look at
EXACTLY what the payload of the PDU would be.  Not just to see
whether the syntax is adequate (though that is an important
concern) but also to make sure we all understand whether the
bits that will be there on the wire are sufficient for the
recipient to automatically generate a sequence of operations
on the correct set of objects from our existing repertoire.
If they aren't, then the subagent protocol would need to be
changed to support the proposal.

I'm not arguing that AgentX should constrain our thinking,
but I do think we need to be very careful when making claims
about just how much (or little) of our existing technologies
can be re-used in an EOS environment.

 Randy Presuhn           randy_presuhn@bmc.com
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San Josť, California 95131  USA
 My opinions and BMC's are independent variables.