Subject: RE: [midcom] SNMPv3

From: "Harrington, David" <[email-masked]>
Date: Fri, 6 Dec 2002 10:36:37 -0500

Hi Juergen,

SETs are done "as if simultaneous", so creating the row, filling the values, and activating the row can all occur in one CreateAndGo operation. I have worked on applications that used CreateAndGo to create, fill, and activate rows with no problem across multiple vendors' devices.

Implementations of RowStatus are required to support CreateAndGo OR CreateAndWait or both. As a result, some implementations do not support the CreateAndGo option or the CreateAndWait option. Typically, a subroutine is developed that tries the CreateAndGo approach first, and if that fails, then the CreateAndWait option is used. 

You correctly pointed out that a multi-PDU transaction would have no impact until the row was made active, using the CreateAndWait/Active settings of RowStatus.

dbh

> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]]
> Sent: Friday, December 06, 2002 7:52 AM
> To: Harrington, David; [email-masked]
> Subject: Re: [midcom] SNMPv3
> 
> 
> David,
> 
> -- Harrington, David wrote on 05 December 2002 20:28 -0500:
> 
> > Hi,
> >
> > I just joined the midcom mailing list to review the 
> discussions, and find some points that need clarification. I 
> have preceded my comments with dbh:
> >
> > Juergen posted the following:
> >
> > I think for most MIDCOM transactions it would not be a problem to
> > fit all parameters into a single PDU. But the SNMP spec saying
> > that the order in which the sets are executed is not deterministic,
> > makes it hard to
> >   1. create a row for a new policy,
> >   2. fill all objects of the row, and
> >   3. set the row to be active (or enabled)
> > with a single PDU. Rather, I think three PDUs are required for
> > this. However, you can still provide atomicity, by having not impact
> > at all on the middlebox behavior after step 1 and 2 and 
> then enabling
> > the policy int the atomic step 3. You can even add to the semantics
> > of step 3 that the entire row will be deleted, if step 3 fails.
> >
> >     Juergen
> >
> > dbh: That is incorrect. The CreateAndGo status for 
> RowStatus allows these steps to be processed in one SET 
> request. See RFC2579.
> >
> 
> When I wrote the statement above, I was aware of the 
> CreateAndGo value for
> RowStatus. Yet, for two reasons I wrote the statement:
> 
> 1. I did not consider this as an inter-operable feature of 
> SNMP. Is it?
>    I thought (so far) that the order in which multiple set operations
>    within one PDU are processed is not determined (i.e. it is
>    implementation specific).  So, if you had 'set row status' and 'set
>    object within the row' in one PDU, this would be fine if you start
>    with 'set row status', but it would fail if you start with 
> the other
>    set operation, because the row does not yet exist.  Only if the
>    SNMP manager (the Midcom agent) knows about the implemented order
>    in which set operations are executed at the SNMP agent (middlebox),
>    the one PDU solution would work always well.
>    But maybe I'm completely wrong and you can tell me where this
>    problem is solved in the SNMPv3 standard track RFCs.
> 
> 2. The discussion above is about Midcom transactions. Creating the row
>    (by CreateAndGo or otherwise) is a pre-requisite for filling the
>    objects in the row with values.  Therefore, logically, the 
> row creation
>    must be performed before set actions on these objects can 
> be performed.
>    But then, setting the row to active must not happen before 
> all other
>    objects in the row are set properly, because setting it to active
>    would request the middlebox to open the pinhole and/or 
> address binding
>    specified by the row.  So, if I use create and go it the 
> create part
>    must be executed by the SNMP agent before setting the 
> other objects of
>    the row, while setting the row to active must - in the Midom case -
>    be executed after setting the other objects of the row.  
> Maybe I'm an
>    ignorant, but even after reading the 8K description of RowStatus in
>    RFC2579, I cannot clearly tell whether the behavior I 
> described is the
>    one that RFC2579 requires.  Again, I would be happy if you could
>    teach me why I'm wrong.
> 
>     Juergen
> 
> 
> > dbh
> >
> > David Harrington
> > Network Management Architect
> > Office of the CTO
> > Enterasys Networks
> >
> > _______________________________________________
> > midcom mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/midcom
> 
> 
> 
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom