Re: Issue 13.3.1 -- I say "go for it"

[Bobby Krupczak <rdk@krupczak.org>]

Hi!

>From the telecomm perspective, lack of an explicit create will make the
>integration of netconf based systems with 3GPP systems difficult; as the
>3GPP network configuration model uses an explicit create.  Just for
>completeness, there is a create, a modify, and a delete.  The service
>providers are used to the explicit creates and the states and notifications
>that arise from its existence.  

As one who partially participated, way back when, in the snmpv2 (my
wife Cheryl participated *a lot* more because she works and plays well
with others much more than myself), we argued for a create operation
as well.  Our argument was basically thus.

Row creations in SNMP are side-effects of SNMP sets.  Side-effects, in
the engineering world, are generally considered poor design.  Why?  As
stated earlier, filtering out poor requests, handling error
conditions, etc.  When implementing SNMP agents (I have some
experience here as developer of SystemEDGE), handling the side-effect
case for tables added quite a bit of complexity to the agent code and
to the MIB design.  MIB specification of row-creations are always
muddled because (among many reasons) the SMI could never quite handle
formal specification of side-effects and thus it was hard to encode
that behavior in code that a computer could understand and process w/o
ambiguity.

However, I guess I should add (for academic honesty) that the lack of
formal row-creation did not fatally inhibit our ability to do
interesting things with tables and row creations.  However, I believe
that the original v2 arguments against row-creation are not as
applicable here.  If I can reach back into the dark corners of my
memory, the arguments against an SNMP row creation were: added code
overhead and protocol overhead with respect to UDP and large rows.
(There may be others; I havent looked at the snmp list archives in a
while nor my own notes.)

As an implementor, I did not feel there was really *any* added code
overhead.  Whether you get to the row-creation "code" via a separate
method routine or via side-effects, it all was pretty much a wash.
However, the code to do row-creations as side-effects is certainly
less clean and more muddled.  (We spent a lot of time fine-tuning
un-wanted side-effects with respect to default values . . .)  The
other argument involved row-creations for large rows which would
necessitate multiple package/message exchanges.  In this case, I felt
the no-create argument had more validity.  But, given the nature of
the emerging netconf protocol, is this argument even valid anymore
given sessions and connections?

Given the deprecation of the rationale against snmp row-create
operation, why not make the "right" engineering choice and add a
create primitive?

Bobby

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>