From mailman-bounces@ietf.org Sun Aug 1 05:28:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05414 for ; Sun, 1 Aug 2004 05:28:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrCFG-0004sX-1F for agentx-archive@lists.ietf.org; Sun, 01 Aug 2004 05:03:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: agentx-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sun, 01 Aug 2004 05:00:59 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for agentx-archive@lists.ietf.org: List Password // URL ---- -------- agentx@ietf.org atabhu https://www1.ietf.org/mailman/options/agentx/agentx-archive%40lists.ietf.org From agentx-bounces@ietf.org Mon Aug 16 18:01:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13968 for ; Mon, 16 Aug 2004 18:01:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwpCg-00020I-UF; Mon, 16 Aug 2004 17:39:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwoxo-0006ig-JU for agentx@megatron.ietf.org; Mon, 16 Aug 2004 17:24:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10994 for ; Mon, 16 Aug 2004 17:24:17 -0400 (EDT) Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwp3g-000422-8H for agentx@ietf.org; Mon, 16 Aug 2004 17:30:24 -0400 Received: from h-66-167-207-64.snvacaid.dynamic.covad.net ([66.167.207.64] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Bwoxm-0006xv-00 for agentx@ietf.org; Mon, 16 Aug 2004 14:24:18 -0700 Message-ID: <00af01c483d7$d02af520$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Date: Mon, 16 Aug 2004 14:27:20 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Agentx] Fw: snmp version-specific behavior in draft-ietf-ipcdn-pktc-mtamib-04.txt X-BeenThere: agentx@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SNMP Agent Extensibility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: agentx-bounces@ietf.org Errors-To: agentx-bounces@ietf.org Hi - FW FYI. Randy > From: "Randy Presuhn" > To: > Sent: Monday, August 16, 2004 2:26 PM > Subject: snmp version-specific behavior in draft-ietf-ipcdn-pktc-mtamib-04.txt > > Hi - > > In draft-ietf-ipcdn-pktc-mtamib-04.txt there are several OBJECT-TYPEs > whose current DESCRIPTIONs will cause implementation difficulties > in RFC 2741 (AgentX) environments. Specifically, pktcMtaDevProvConfigKey, > pktcMtaDevProvSolicitedKeyTimeout, pktcMtaDevProvUnsolicitedKeyMaxTimeout, > pktcMtaDevProvUnsolicitedKeyNomTimeout, and > pktcMtaDevProvUnsolicitedKeyMaxRetries, all require special > errors to be generated depending on the "provisioning mode", > which appears to be the protocol used to access the object instance. > > AgentX provides no way for a subagent to know what protocol version > was used to transport a request, so this kind of specification effectively > precludes implementation in those environments. > > I would strongly suggest that it would make more sense to remove these > statements about the implementation of access control policy from the > OBJECT-TYPE descriptions, and put the material in the security > considerations section where it belongs. > > In any case, the mandated behavior should be identical to that > which would be encountered if access had been denied due to access > control, whether using VACM or some other access control model. > > Randy > >