Re: Methods, Inheritance, Exceptions, etc. (was: Re: Methods in SMIng ?)

[Andy Bierman <abierman@cisco.com>]

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