Subject: [midcom] SNMPv3

From: "Harrington, David" <[email-masked]>
Date: Thu, 5 Dec 2002 20:28:00 -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.

dbh

David Harrington
Network Management Architect
Office of the CTO
Enterasys Networks
 
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 05 Dec 2002 22:52:47 -0800

>>>>> On Thu, 5 Dec 2002 20:28:00 -0500, "Harrington, David" <[email-masked]> said:

Juergen> I think for most MIDCOM transactions it would not be a problem to
Juergen> fit all parameters into a single PDU. But the SNMP spec saying
Juergen> that the order in which the sets are executed is not
Juergen> deterministic,

FYI, the EOS working group is producing a document with SNMP write
transactions which do support transactional ordering if desired.  IE,
within the new write PDU you can delete a row and replace it with new
contents in the same operation by ordering the transaction.

-- 
Wes Hardaker
Network Associates Laboratories
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 06 Dec 2002 13:51:45 +0100

David,

> 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

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 06 Dec 2002 13:58:51 +0100

Wes,

> contents in the same operation by ordering the transaction.

Can you give me a reference to this document?
I could not find it on the EOS charter page.

Thank you,

    Juergen

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 06 Dec 2002 08:42:21 -0800

>>>>> On Fri, 06 Dec 2002 13:58:51 +0100, Juergen Quittek <[email-masked]> said:

Juergen> Can you give me a reference to this document?
Juergen> I could not find it on the EOS charter page.

The draft hasn't been officially published as a WG item, but will be
in the next couple of weeks (the end of next week if I'm lucky).  In
the mean time, here is a copy of the draft that was discussed at the
EOS meeting in Atlanta:

  http://eos.hardakers.net/draft-hardaker-eos-oops-02pre.txt

I'm particularly interested in people's thoughts on the write
operations contained within, as I haven't gotten much feedback on the
subject (I've gotten a lot on the get operations).  I can tell you
that the write semantics contained in the document are in line with
what you've expressed a need for.

Warning: document far from complete but should be better when it's
first published as a WG item.  The PDU structures have changed
slightly as well since then, but the concepts are still t same.