Delivery-Date: Thu, 03 Oct 1996 08:54:03 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id IAA09009 for X-agentx; Thu, 3 Oct 1996 08:54:03 -0700 (PDT) Received: from emptech.empiretech.com (emptech.empiretech.com [198.17.251.1]) by fv.com (8.7.4/8.7.3) with SMTP id IAA08976 for ; Thu, 3 Oct 1996 08:54:01 -0700 (PDT) Received: from celestial (celestial.empiretech.com [198.17.251.11]) by emptech.empiretech.com (8.6.12/8.6.12) with ESMTP id LAA19086 for ; Thu, 3 Oct 1996 11:54:11 -0400 Received: (from cheryl@localhost) by celestial (8.6.12/8.6.12) id LAA18512 for agentx@fv.com; Thu, 3 Oct 1996 11:54:09 -0400 From: cheryl@empiretech.com (Cheryl Krupczak) Message-Id: <199610031554.LAA18512@celestial> Subject: Meeting time in San Jose? To: agentx@fv.com Date: Thu, 3 Oct 1996 11:54:09 -0400 (EDT) X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Has a meeting time been reserved yet for the IETF in San Jose? If so, when is it? Thanks! cheryl +--------------------------------------------------------------------+ + Check us out! http://www.empiretech.com/empiretech + +--------------------------------------------------------------------+ + Cheryl Krupczak Empire Technologies, Inc. + + cheryl@empiretech.com 541 Tenth Street NW + + PH : (770)384-0184 Suite 169 + + FAX: (770)384-0183 Atlanta, GA 30318 + +--------------------------------------------------------------------+   Delivery-Date: Thu, 03 Oct 1996 10:38:01 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id KAA21238 for X-agentx; Thu, 3 Oct 1996 10:38:01 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by fv.com (8.7.4/8.7.3) with SMTP id KAA21231 for ; Thu, 3 Oct 1996 10:38:00 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id NAA02257; Thu, 3 Oct 1996 13:38:11 -0400 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA21603; Thu, 3 Oct 1996 13:36:51 -0400 Date: Thu, 3 Oct 1996 13:37:13 EDT From: Bob Natale Subject: Re: Meeting time in San Jose? [AgentX] To: Cheryl Krupczak Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Cheryl Krupczak > Date: Thu, 3 Oct 1996 11:54:09 -0400 (EDT) Hi Cheryl, > Has a meeting time been reserved yet for the IETF in San Jose? A single meeting slot has been requested. The purpose of this meeting will be to focus on implementation issues. We will have a new, final draft (#5) of the spec on the list in a day or two. Other than typos and similar edits, this will be the version that will go in the I-D repository before the cut-off date (11/13?). I will make additional appeals and offer some guidance wrt implementation of the spec shortly after it is posted to the list. The focus of the San Jose meeting will be on any changes to the spec indicated from implementation and interoperability experience up to that point. > If so, when is it? We should know soon. We are trying to avoid conflicts with the disman, applmib, and rmon groups. I will post the info on the list as soon as I get it. Thanks. Cordially, BobN ------ ISO 9000 Registered, Hardware and Software Divsions ----- Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ---------- WinSNMP DLL, SDK, and Apps for Win16/Win32 ---------- ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Fri, 04 Oct 1996 08:26:31 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id IAA14414 for X-agentx; Fri, 4 Oct 1996 08:26:31 -0700 (PDT) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by fv.com (8.7.4/8.7.3) with ESMTP id IAA14411 for ; Fri, 4 Oct 1996 08:26:29 -0700 (PDT) Received: from hunch.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id LAA06726; Fri, 4 Oct 1996 11:26:47 -0400 (EDT) Received: from bernie.zk3.dec.com by hunch.zk3.dec.com; (5.65v3.2/1.1.8.2/11Mar96-0342PM) id AA28708; Fri, 4 Oct 1996 11:26:47 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA17979; Fri, 4 Oct 1996 11:30:12 -0400 Message-Id: <9610041530.AA17979@bernie.zk3.dec.com> To: agentx@fv.com Subject: status report Date: Fri, 04 Oct 96 11:30:12 -0400 From: Mike Daniele X-Mts: smtp Hi, The WG chair and I went over the feedback from versions 3 and 4, and made some decisions. In cases where we didn't detect rough concensus, we choose the simplest approach. A draft of Version 5 is in the hands of the editor, but I wanted to update everyone on changes it contains: 1. unionized registrations were removed. Duplicate registrations (same region, same priority, same context) are failed. 2. registration for "all contexts" was removed. A single non-default context may be passed in all PDUs. It is an optional field, present only when the CTX_NON_DEFAULT bit is set. If the bit is clear, the PDU refers to the default context. 3. the snmp version field was removed from the header. The elements of procedure were updated everywhere to reflect these changes. 4. overlapping registrations (sub 1 registers `mib-2', sub 2 registers 'ip') are still supported, as this was viewed as fundamental to permitting independently developed subagents to coexist. 5. the cluster-wide registration bit was removed. 6. sysORTable data accompanies Register-PDUs, not the Open-PDU. 7. New agentX-specific error codes (for res.error) were defined for the "adminstrative" operations, instead of reusing (overloading) SNMPv2 error codes. 8. An IndexUnrsrv-PDU was added, for subagents to release previously reserved index values. the procedure for reserving indexes was updated to support requesting a never-used or previously-used index value. (ala David Battle instance reservation mib) 9. numerous (editorial) changes were included, more accurate/descriptive text, fixed typos, etc. Thanks to all you reviewers. Mike   Delivery-Date: Wed, 09 Oct 1996 11:59:03 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id LAA17863 for X-agentx; Wed, 9 Oct 1996 11:59:02 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by fv.com (8.7.4/8.7.3) with ESMTP id LAA17809 for ; Wed, 9 Oct 1996 11:58:53 -0700 (PDT) Received: from flume.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id OAA25980; Wed, 9 Oct 1996 14:58:56 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA01033; Wed, 9 Oct 1996 14:58:52 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA20367; Wed, 9 Oct 1996 15:02:18 -0400 Message-Id: <9610091902.AA20367@bernie.zk3.dec.com> To: agentx@fv.com Subject: re: encoding and pdus Date: Wed, 09 Oct 96 15:02:18 -0400 From: Mike Daniele X-Mts: smtp >From: Don Ryan >To: "'agentx@fv.com'" >Subject: encoding and pdus >Date: Mon, 16 Sep 1996 00:00:43 -0700 >X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 >X-Suppressed-Encoding: 763 TEXT >Here are some ideas I had over the weekend about the AgentX encodings >and PDUs. Hi Don, Thanks for an excellent posting. This reply contains a brief discussion of your ideas wrt version 5 of the draft. Comments from the group welcome. Regards, Mike > Numeric data in all AgentX headers is in network byte order. The byte >order of numeric data within the AgentX PDUs is specified by the PDU-specific >flag X_FLAG_NETWORK_BYTE_ORDER. It is important to note that subagents >always read and write numeric data in the PDUs using the subagent's natural >byte ordering and that their only responsibility is to set the above flag >correctly. AgentX master agents are responsible for translating the byte >order in incoming and outgoing PDU's. This will only be necessary, however, >if the master agent's own ordering differs from that of the subagent. This is an excellent idea, which was included in the draft version 5. Since the master agent initiates many PDUs, it must remember each sub's preference. So I only discussed the bit in the Open-PDU, and don't mention it elsewhere. (In other words, it's a per subagent characteristic, not per PDU). >5.1 Object Identifier > > An object identifier is transmitted as a 32-bit value describing the >number of sub-identifiers present followed by the 32-bit sub-identifiers >themselves. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Number of Sub-Identifiers (S) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sub-Identifier 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sub-Identifier S | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and 5.3.1 Variable Name > > A name component of a variable binding is transmitted as a 32-bit view >identifier describing the registered view containing the variable followed by >an partial object identifer describing the variable. This partial object >identifier is relative to view prefix registered with the view identifier as >described in section 6.3.3. If the object identifier is not relative to any >view (as is the case in trap variable names) then the view identifier should >be set to the reserved value of 0xFFFFFFFF. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | View Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Name Object Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... I didn't include this because the existing scheme seems simpler (neither side has to remember view identifiers, especially per context) and more general. (Object Identifiers are frequently used that don't reference a registered region.) >5.2 Octet String > > A octet string is transmitted as a 32-bit value describing the number of >octets in the octet string followed by the octets themselves. If the octet >string is not positioned at the end of a PDU then padding octets should be >added to maintain 32-bit alignment. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Octet String Length (L) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Octet 1 | Octet 2 | Octet 3 | Octet 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Octet L - 1 | Octet L | Optional Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I included this in v5. It makes passing around contexts and descriptive text (o.descr, r.or_descr) much much simpler. >5.3.2 Variable Value > > A value component of a variable binding is transmitted as a 32-bit type >identifier followed by the value data transmitted as outlined in the comments >below. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value Data | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... I included the idea of removing the value size, and any description of padding, from the VarBind. The variable length types each now have a specific encoding that contains a length. 6.1 AgentX Message Header > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version | Next Header | Total Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > I included this basic layout, redefining payload length. I didn't bite on the extension headers though. Our model has always been "just define new PDU types" so I didn't want to make a relatively large change at this point. 6.2 AgentX PDU Header > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PDU Type | PDU Flags | PDU Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Connection Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I've received a couple of questions off-list about a subagent id, so wanted to bring this up. We currently don't carry such a connection or session id in the protocol, and assume both sides can identify the "session" based on (transport layer) information about the other side. Given our current transport mappings, and conventional network support (sockets, etc) this is easy to do. But I wanted to bring it up and invite comments from the work group. >6.3.5 AgentX Get PDU > > The master agent sends an agentx-Get-PDU to the subagent in order to >resolve variables determined to be contained in the views registered by the >subagent. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PDU Type = 5 | PDU Flags | PDU Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Connection Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Number of Variables (V) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Name 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Name V | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I didn't include a "number of variables" field. With the new Octet String encoding, VarBindLists are always at the end of the PDUs, so it's not needed (and not part of the reference implementations). >6.3.8. AgentX Test PDU > > The master agent sends an agentx-Test-PDU to the subagent in order to >validate variables determined to be contained in the views registered by the >subagent which are to be set. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PDU Type = 8 | PDU Flags | PDU Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Connection Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Number of Variable Bindings (V) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Binding 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Binding V | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... We don't include a Set ID currently, the idea being (I believe) that after sending a Test-PDU, the master won't send any other PDUs except the Commit/Undo/Cleanup PDUs that finish processing this operation. These are protocol "states" we should probably list. >6.3.13 AgentX Ping PDU > > The subagent sends an agentx-Ping-PDU to the master agent in order to test >that the master agent is running and responding promptly and vice versa. > > 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PDU Type = 13 | PDU Flags | PDU Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Connection Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >PDU Flags - optional characteristics of PDU: > > Bit > --- > 0 X_FLAG_NETWORK_BYTE_ORDER > 1 X_FLAG_ARE_YOU_ALIVE > 2 X_FLAG_I_AM_ALIVE > 3-7 unused (must be zero) > > X_FLAG_ARE_YOU_ALIVE - if 1 indicates that the sender of the > agentx-Ping-PDU is requesting a status report in the form of > a agentx-Ping-PDU with the X_FLAG_I_AM_ALIVE flag set. > > X_FLAG_I_AM_ALIVE - if 1 indicates that the sender of the > agentx-Ping-PDU is running and reponding. We simply have Ping and Response. Our thinking has been we really only need it for the subagent to determine if the master is alive. The master doesn't need to broadcast it's health, and can determine (via transport errors or timeouts) if the sub is not healthy.   Delivery-Date: Wed, 09 Oct 1996 15:42:21 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id PAA10750 for X-agentx; Wed, 9 Oct 1996 15:42:20 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by fv.com (8.7.4/8.7.3) with SMTP id PAA10746 for ; Wed, 9 Oct 1996 15:42:19 -0700 (PDT) Received: by mail2.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.29) id <01BBB5F6.DEB47010@mail2.microsoft.com>; Wed, 9 Oct 1996 15:30:58 -0700 Message-ID: From: Don Ryan To: "'Mike Daniele'" Cc: "'agentx@fv.com'" Subject: RE: encoding and pdus Date: Wed, 9 Oct 1996 15:31:43 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.29 Encoding: 271 TEXT Hi Mike, >---------- >From: Mike Daniele[SMTP:daniele@zk3.dec.com] >Sent: Wednesday, October 09, 1996 12:02 PM >To: agentx@fv.com >Subject: re: encoding and pdus > >>5.1 Object Identifier >> >> An object identifier is transmitted as a 32-bit value describing the >>number of sub-identifiers present followed by the 32-bit sub-identifiers >>themselves. >> >> 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 >> 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Number of Sub-Identifiers (S) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sub-Identifier 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sub-Identifier S | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >My assumption here was that AgentX will used as an IPC mechanism much more >than it will be used as an on-the-wire protocol. The structures should be >kept simple and should be designed in such a way that the subagent can read >the variable names and values directly from the receive buffer with no >decoding. >I do not have a problem with your prefix number although I thought it might >be more useful to the subagent developer to be able to specify a prefix >during view registration. This prefix would only be used for variable names >(not variable values which are OIDs) and therefore would always be in the >subagent's supported view. The subagent does not have to inspect the OID to >see if it has been compressed because the subagent has specified the prefix >and will always be passed an OID minus that prefix. Since extensible agents >have to maintain a record of some sort matching the MIB region to the >subagent supporting that region, adding another 32-bit field to this record >is not that painful. Subagents can always specify a zero-length prefix if >they wish to deal with fully qualified OIDs. >I do have a problem with embedding flags in structures which are only >meaningful in certain PDUs (e.g., the OID include flag). It would be much >cleaner to specify any options in the context in which those options are >meaningful (i.e., in the SearchRange structure) rather than in the OID itself >which could be used in other contexts. > >5.3.1 Variable Name >> >> A name component of a variable binding is transmitted as a 32-bit view >>identifier describing the registered view containing the variable followed >>by >>an partial object identifer describing the variable. This partial object >>identifier is relative to view prefix registered with the view identifier as >>described in section 6.3.3. If the object identifier is not relative to any >>view (as is the case in trap variable names) then the view identifier should >>be set to the reserved value of 0xFFFFFFFF. >> >> 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 >> 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | View Identifier | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Name Object Identifier | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ... > >I didn't include this because the existing scheme seems simpler (neither >side has to remember view identifiers, especially per context) and more >general. (Object Identifiers are frequently used that don't reference >a registered region.) Object identifiers used in variable names (not variable values) should be in the registered region. The only exceptions might be asking the agent asking the subagent for the first object in the supported view (in which can the agent could pass a zero-length OID) and having the subagent report the end of the view (handled via exceptions anyway). The main reason for the View Identifier is eliminate the need for the subagent to immediately duplicate the extensible agent's efforts in determining which supported view the specified variable is from. If I have a subagent which supports N mib regions in M contexts (NxM views total) and the extensible agent simply passes the subagent an OID and OCTETSTRING then the subagent must potentially rummage through the M contexts and the N regions looking for the correct information with which to process the request. The extensible agent just did almost exactly the same rummaging in order to determine which subagent to query. At the expense of another 32-bit value in the MIB region record and another 32-bit value in each variable name, the subagent could specify a View Identifier in order to quickly determine the view (and processing context). It is important to remember this value is opaque to the extensible agent. In playing around with this idea, I found it particularly useful for subagents with many views and for shims to other agents because the processing context is easily retreived. > >6.1 AgentX Message Header >> >> 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 >> 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Version | Next Header | Total Payload Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > >I included this basic layout, redefining payload length. I didn't >bite on the extension headers though. Our model has always been >"just define new PDU types" so I didn't want to make a relatively >large change at this point. I did not have much hope for the extension headers. I am, however, concerned about having random subagents attaching from the network without any form of password or authentication. Among other things, I was contemplating denial of service attacks where rogue subagents add and delete views in a tight loop, reserve massive numbers of table indices, etc etc. > >6.2 AgentX PDU Header >> >> 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 >> 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | PDU Type | PDU Flags | PDU Payload Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Connection Identifier | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >I've received a couple of questions off-list about a subagent id, so >wanted to bring this up. > >We currently don't carry such a connection or session id in the protocol, >and assume both sides can identify the "session" based on (transport layer) >information about the other side. > >Given our current transport mappings, and conventional network support >(sockets, etc) this is easy to do. But I wanted to bring it up and >invite comments from the work group. The reason I added the Connection Identifier was to separate the subagent logical connection and transport connection. This allows connectionless protocol support but also helps limit the number of connections a subagent shim needs to open. Each connection to the shim can be reprsented as a logical connection to the agentx master agent piggybacking on the same transport connection. I found it very useful myself. >>6.3.5 AgentX Get PDU >> >> The master agent sends an agentx-Get-PDU to the subagent in order to >>resolve variables determined to be contained in the views registered by the >>subagent. >> >> 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 >> 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | PDU Type = 5 | PDU Flags | PDU Payload Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Connection Identifier | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Request Identifier | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Number of Variables (V) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Variable Name 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Variable Name V | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >I didn't include a "number of variables" field. With the new Octet String >encoding, VarBindLists are always at the end of the PDUs, so it's not >needed (and not part of the reference implementations). I like my data structures to be very explicit about their content. Your assumption is the only reason I want the number of bindings is to walk the structure. My contention is that I should not have to walk the structure to find out how many elements are inside. I will probably use this count before walking the structure anyway in order to initialize a wrapper structure for example. Limiting the number of bytes of a structure repeated throughout a PDU I can understand. Limiting the number of bytes of value that occurs once per PDU (and which can be very useful) I do not agree with. > >>6.3.8. AgentX Test PDU >> >> The master agent sends an agentx-Test-PDU to the subagent in order to >>validate variables determined to be contained in the views registered by the >>subagent which are to be set. >> >> 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 >> 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | PDU Type = 8 | PDU Flags | PDU Payload Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Connection Identifier | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Request Identifier | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set Identifier | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Number of Variable Bindings (V) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Variable Binding 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Variable Binding V | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ... > >We don't include a Set ID currently, the idea being (I believe) that >after sending a Test-PDU, the master won't send any other PDUs >except the Commit/Undo/Cleanup PDUs that finish processing this operation. > >These are protocol "states" we should probably list. The Set Identifier was an easy way for the agent and the subagent to enforce state and limit traffic. It served to quickly identify the VarBindList so the subagent did not have to perform a VarBindList (and context) comparision in order to determine that a COMMIT matched a given TEST PDU. A subagent might have allocated storage which can be quickly retreived via this identifier. >>6.3.13 AgentX Ping PDU >> >> The subagent sends an agentx-Ping-PDU to the master agent in order to >>test >>that the master agent is running and responding promptly and vice versa. >> >> 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 >> 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | PDU Type = 13 | PDU Flags | PDU Payload Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Connection Identifier | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Request Identifier | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>PDU Flags - optional characteristics of PDU: >> >> Bit >> --- >> 0 X_FLAG_NETWORK_BYTE_ORDER >> 1 X_FLAG_ARE_YOU_ALIVE >> 2 X_FLAG_I_AM_ALIVE >> 3-7 unused (must be zero) >> >> X_FLAG_ARE_YOU_ALIVE - if 1 indicates that the sender of the >> agentx-Ping-PDU is requesting a status report in the form of >> a agentx-Ping-PDU with the X_FLAG_I_AM_ALIVE flag set. >> >> X_FLAG_I_AM_ALIVE - if 1 indicates that the sender of the >> agentx-Ping-PDU is running and reponding. > >We simply have Ping and Response. Our thinking has been we really only need >it for the subagent to determine if the master is alive. The master doesn't >need to broadcast it's health, and can determine (via transport errors or >timeouts) >if the sub is not healthy. This was actually put in to support the agentx master loading a UDP-based subagent remotely. The master would have the address/port of the subagent and PINGs the subagent to start the connection process. I had too much time on my hands that weekend I suppose. Regards, >Don   Delivery-Date: Wed, 16 Oct 1996 07:32:47 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id HAA09077 for X-agentx; Wed, 16 Oct 1996 07:32:47 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by fv.com (8.7.4/8.7.3) with SMTP id HAA09072 for ; Wed, 16 Oct 1996 07:32:42 -0700 (PDT) Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id KAA23798; Wed, 16 Oct 1996 10:32:52 -0400 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA03463; Wed, 16 Oct 1996 10:32:30 -0400 Date: Wed, 16 Oct 1996 10:31:58 EDT From: Bob Natale Subject: AgentX meeting at San Jose IETF To: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi Everyone, We will hold a single AgentX meeting at the forthcoming IETF: Wednesday, December 11 at 0900 (opposite tagsw-bof, dnssec, rtfm) The final draft of the I-D will be posted to the list by the end of this week. Comments wrt cosmetic changes--i.e., typos, nits, obvious omissions, minor stylistic improvements, etc.--will be welcome and considered before the cut-off date for submission to the IETF (I'll have to check that date, but I think it's November 13 or so). If Maria and/or the wg in general has the time, it will be helpful if we can bring the MIB draft up-to-date wrt the draft protocol I-D when it is posted. Comments wrt agenda items for the IETF meeting are invited starting now. The focus however will be on implementation and interoperability wrt the protocol I-D and secondary documents (e.g., the MIB, other IETF standards, etc.). Reports based on actual experience up to that point will be very warmly welcomed, but reports based on analysis only will not be out of scope. Also, clearly, the mechanics of advancing the AgentX protocol I-D along the standards track at that point will have to be discussed. If you have any comments/suggestions wrt any aspect of this planned approach, please post them asap. I am hopeful that the following people will be able to attend the meeting and make [semi-]formal presentations (within the focus/scope mentioned above): Mike Daniele Dale Francisco Bert Wijnen Maria Greene Don Ryan Randy Presuhn Jeff Case That list is not meant to be exclusive at all...just that they have each played an individually significant part in forming the protocol and I would like to be sure to include their observations at that point in the official record of this meeting. Anyone else who wants to make a presentation is heartily encouraged to do so. I would appreciate it if all of you who intend to be there and make such a presentation would let me know asap. If you are not going to be there and would still like to make a presentation, either designate a representative or send me your material (text or PowerPoint) and I will represent you. For the record, ACE*COMM plans to do a WinSNMP-based AgentX implementation (master and selected subagents) and I will report on that effort. Cordially, BobN ------ ISO 9000 Registered, Hardware and Software Divsions ----- Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ---------- WinSNMP DLL, SDK, and Apps for Win16/Win32 ---------- ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Wed, 16 Oct 1996 13:06:25 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id NAA11925 for X-agentx; Wed, 16 Oct 1996 13:06:24 -0700 (PDT) Received: from mwunix.mitre.org (mwunix.mitre.org [128.29.154.1]) by fv.com (8.7.4/8.7.3) with SMTP id NAA11917 for ; Wed, 16 Oct 1996 13:06:23 -0700 (PDT) Received: from TGATE1 (tgate1.mitre.org [128.29.154.210]) by mwunix.mitre.org (8.6.10/8.6.4) with SMTP id QAA28221 for ; Wed, 16 Oct 1996 16:06:36 -0400 Received: from mail04.mitre.org (128.29.101.3) by tgate1.mitre.org (EMWAC SMTPRS 0.60) with SMTP id ; Wed, 16 Oct 1996 16:01:11 -0400 Received: by mail04.mitre.org; (5.65v3.0/1.1.8.2/22Jun94-0628PM) id AA20633; Wed, 16 Oct 1996 16:06:35 -0400 Subject: unsubscribe From: nour@mail04.mitre.org (Nina N. Nour) To: agentx@fv.com (agentx@fv.com) Message-Id: <961016160634.21340@mail04.mitre.org.0> Date: Wed, 16 Oct 96 16:06:34 -0400 X-Mailer: MailWorks 2.0 unsubscribe   Delivery-Date: Mon, 28 Oct 1996 00:57:05 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id AAA00558 for X-agentx; Mon, 28 Oct 1996 00:57:04 -0800 (PST) Received: from bpcsee.cie-signaux.fr (bpcsee.cie-signaux.fr [194.2.40.1]) by fv.com (8.7.4/8.7.3) with ESMTP id AAA00529 for ; Mon, 28 Oct 1996 00:57:01 -0800 (PST) Received: from cstelecom.com (oass03 [194.2.42.20]) by bpcsee.cie-signaux.fr with SMTP id KAA12868; Mon, 28 Oct 1996 10:56:23 +0100 (MET) Received: from oass05.cstelecom.com by cstelecom.com id AA07588; Mon, 28 Oct 96 10:55:42 +0100 Received: by oass05.cstelecom.com (SMI-8.6/SMI-SVR4) id JAA18000; Mon, 28 Oct 1996 09:59:02 +0100 Date: Mon, 28 Oct 1996 09:59:02 +0100 From: brenet@cie-signaux.fr (Vincent Brenet) Message-Id: <199610280859.JAA18000@oass05.cstelecom.com> To: agentx@fv.com Subject: cache-ahead between master and subagents Cc: brenet@oass03.cie-signaux.fr X-Sun-Charset: US-ASCII Hello, I read in SMUX RFC (RFC 1227): "There are two approaches that can be taken when trying to integrate arbitrary MIB modules with the SNMP agent: request-response and cache-ahead. ... The cache-ahead model requires that the SMUX peer, after registration, periodically updates the SNMP [master] agent with the subtree for the MIB module which has been registered. ... that document describe only the SMUX protocol, for the request-response model. Each SMUX peer is free to define a cache-ahead protocol specific for the application at hand." So my question is: do you have the same approach in the Working Group (i.e. not taking cache-ahead into account), or do you work about an explicit cache-ahead mechanism between the master agent and the subagent ? Thanks   Delivery-Date: Mon, 28 Oct 1996 07:24:29 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.4/8.7.3) id HAA01319 for X-agentx; Mon, 28 Oct 1996 07:24:29 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by fv.com (8.7.4/8.7.3) with ESMTP id HAA01315 for ; Mon, 28 Oct 1996 07:24:28 -0800 (PST) Received: from hunch.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id KAA22841; Mon, 28 Oct 1996 10:11:22 -0500 (EST) Received: from bernie.zk3.dec.com by hunch.zk3.dec.com; (5.65v3.2/1.1.8.2/11Mar96-0342PM) id AA14506; Mon, 28 Oct 1996 10:11:19 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA27132; Mon, 28 Oct 1996 10:14:47 -0500 Message-Id: <9610281514.AA27132@bernie.zk3.dec.com> To: brenet@cie-signaux.fr (Vincent Brenet) Cc: agentx@fv.com Subject: Re: cache-ahead between master and subagents In-Reply-To: Your message of "Mon, 28 Oct 96 09:59:02 +0100." <199610280859.JAA18000@oass05.cstelecom.com> Date: Mon, 28 Oct 96 10:14:46 -0500 From: Mike Daniele X-Mts: smtp Hi, >I read in SMUX RFC (RFC 1227): >"There are two approaches that can be taken when trying to integrate >arbitrary MIB modules with the SNMP agent: request-response and cache-ahead. > ... >The cache-ahead model requires that the SMUX peer, after registration, >periodically updates the SNMP [master] agent with the subtree for the >MIB module which has been registered. > ... >that document describe only the SMUX protocol, for the request-response model. >Each SMUX peer is free to define a cache-ahead protocol specific for >the application at hand." >So my question is: do you have the same approach in the Working Group >(i.e. not taking cache-ahead into account), or do you work about an explicit cache-ahead >mechanism between the master agent and the subagent ? We have the same approach, and have use only a request-response protocol for accessing MIB variables. Mike