I am also worried that a piece meal approach will not produce the best solution. That said, what changes would be required to the draft-ietf-eos-rowops-00.txt document to allow for methods? Rowops is already specifying a new set of PDUs -- could these PDUs be changed to meet the existing RowOps requirements and the SMIng requirements?
/gww
> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]
> Sent: Monday, May 7, 2001 12:59
> To: Juergen Schoenwaelder
> Cc: andreaw@cisco.com; sming@ops.ietf.org
> Subject: Re: Methods, Inheritance, Exceptions, etc. (was: Re: Methods in
> SMIng ?)
>
> Juergen Schoenwaelder wrote:
> >
> > >>>>> Andrea Westerinen writes:
> >
> > Andrea> Juergen, You say ... "I am looking for someone who shows a
> > Andrea> concrete proposal how a generic method signature maps to our
> > Andrea> current set of SNMP protocol operations."
> >
> > Andrea> I agree - but view the "workarounds" first as an existence
> > Andrea> proof that this support is needed, and that it can be done.
> > Andrea> Also, I view these proposals as possible mechanisms that
> > Andrea> should be discussed as to their pros and cons. I do not want
> > Andrea> to rathole on a proposal at this time, when the issue is
> > Andrea> whether procedure signatures (moving to Frank's term) are
> > Andrea> required.
> >
> > Andrea> Since there are cases where these are already used in MIBs,
> > Andrea> and where most folks acknowledge that cleaner semantics would
> > Andrea> be helpful, I believe that these are a requirement. Next, we
> > Andrea> can move to the mechanism.
> >
> > We are after all formulating requirements for SMIng to be addressed by
> > the SMIng working group under the SMIng charter.
> >
> > I continue to believe that methods require special protocol support
> > unless we go for what I would call a really really ugly hack. Note
> > that the SMIng WG is not supposed to do protocol work.
> >
> > I still doubt that requiring methods _now_ for SMIng makes sense - it
> > might lead (a) to a mechanism we really do not want or (b) to a
> > situation where we do not finish SMIng or (c) to a situation where you
> > can specify methods but the definition is just mapped to nothing.
>
> I agree -- that's why I brought the issue up on the EOS (15-jan-01):
>
> I propose that the initial charter also include the following item to
> support
> current work in the SMIng WG:
>
> - A standards-track document defining mechanisms for supporting
> object-oriented transactions (i.e. OO methods), such as a variant of
> the
> SetPDU in which additional varbinds may be be returned in the
> ResponsePDU.
> Other protocol extensions for support of OO mechanisms defined in
> the SMIng WG may also be needed.
>
> The responses from the EOS co-chair and co-AD have been quite
> consistent, and it's clear they want to defer this work until after
> the current charter is completed. I accepted this decision back in January,
> and I figured that was the end of methods in SMIng for awhile.
>
> I share your concerns about a piece-meal process, done in series with EOS
> rather than in parallel. SNMP Set is already more work on agent developers
> than can be cost-justified, we don't need any hacks built on top of the
> current
> protocol capabilities to make it worse.
>
> All that said, I think a method-oriented Set PDU would fix SNMP-Set,
> because methods are more aligned with how the CLI code works:
> - one command processed by the agent at a time
> - the entire command is processed at once, even if fragmentation
> of the input occurs.
>
> We need documentation mechanisms defined in SMIng (something like the
> LIBRARY-TYPE and FUNCTION macros defined in draft-bierman-disman-see-00.txt)
> and efficient mappings to SNMP (and COPS-PR) defined elsewhere, which make
> agent development simpler. I think we should either figure out how to defer
> this work for 6 more months in order to align with the EOS schedule, or get
> EOS to
> change its schedule. (The former seems more reasonable ;-)
>
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder Technical University Braunschweig
> > <schoenw@ibr.cs.tu-bs.de> Dept. Operating Systems & Computer Networks
> > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany
> > Fax: +49 531 391 5936 <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>
>
> Andy