From mark@ellisonsoftware.com Tue Sep 1 04:53:50 2009 Return-Path: X-Original-To: agentx@core3.amsl.com Delivered-To: agentx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 209673A6997 for ; Tue, 1 Sep 2009 04:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.327 X-Spam-Level: X-Spam-Status: No, score=-101.327 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kZHiq0Z-tQ9 for ; Tue, 1 Sep 2009 04:53:49 -0700 (PDT) Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com [209.85.211.174]) by core3.amsl.com (Postfix) with ESMTP id 432A03A6880 for ; Tue, 1 Sep 2009 04:53:49 -0700 (PDT) Received: by ywh4 with SMTP id 4so8987401ywh.17 for ; Tue, 01 Sep 2009 04:53:58 -0700 (PDT) MIME-Version: 1.0 Sender: mark@ellisonsoftware.com Received: by 10.150.240.15 with SMTP id n15mr11394626ybh.212.1251806038083; Tue, 01 Sep 2009 04:53:58 -0700 (PDT) In-Reply-To: <1251750777.5149.52.camel@sara.home> References: <1251623843.6043.6.camel@sara.home> <8a0268750908301048i2b4a477dod97e582238098bbe@mail.gmail.com> <1251668476.3736.14.camel@sara.home> <8a0268750908301523o390d9ff1kc951bfb24d49c9e1@mail.gmail.com> <1251750777.5149.52.camel@sara.home> Date: Tue, 1 Sep 2009 07:53:58 -0400 X-Google-Sender-Auth: cd19456a50f72bd3 Message-ID: <8a0268750909010453ld959065ife382929301ace69@mail.gmail.com> From: Mark Ellison To: Magnus Fromreide Content-Type: text/plain; charset=ISO-8859-1 Cc: agentx@ietf.org Subject: Re: [Agentx] Empty context in rfc2742 X-BeenThere: agentx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SNMP Agent Extensibility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 11:53:50 -0000 Hi Magnus On Mon, Aug 31, 2009 at 4:32 PM, Magnus Fromreide wrote: > > As I understand 2742 agentxRegistrationTable is a view into the set of > registrations that the sessions have done with the master agent and thus > the values of that table should match the values in the actual > registrations as far as possible. Agreed. > While this is true it is also true that the agent is free to map the > AgentX-contexts to SNMP-contexts however it wish so I think this impose > no limits on the values of AgentX-contexts. Disagreed. > This question is only regarding the _values_ of the agentxRegContext > column. > > As I said above it believe that agentxRegContext should represent the > values of the AgentX-context for all AgentX-registrations that is made > on the AgentX-side of the master agent. Agreed. > The problem is that the value set for AgentX-context contains one > element more than the value set for OCTET STRING. > > I am asking how the AgentX-context value that don't fit into the mapping > from AgentX-context to agentxRegContext should be handled. > > EXAMPLE: > > Assume that two AgentX registrations are made to a master agent that > implements rfc 2741 and rfc 2742. > > 1: { r.flags = 0, , ... } > 2: { r.flags = NON_DEFAULT_CONTEXT, r.context = "", ... } > > Now as I read 2742 the value of the agentxRegContext column for > registration #1 is "" Agreed. > The question is what the value of the agentxRegContext column for > registration #2 should be? I think the agent should reject this registration and suggest that the agent should accept registrations in the non default context only when the r.context length > 0. The zero-length context name is reserved for the default context. This is because the AgentX context names are mapped from SNMP context names - RFC 3411, section 3.3 shows the default context as being the zero-length string. Non-default context names have a string length greater than zero. As such, it stands to reason that an AgentX registration per #2 above will not be visible to an SNMP client/manager/command-generator application and serves no useful purpose. -- Mark From randy_presuhn@mindspring.com Tue Sep 1 12:15:15 2009 Return-Path: X-Original-To: agentx@core3.amsl.com Delivered-To: agentx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D06F228C72C for ; Tue, 1 Sep 2009 12:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.663 X-Spam-Level: X-Spam-Status: No, score=-0.663 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMhOamHZW4WM for ; Tue, 1 Sep 2009 12:15:15 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id ED0413A6C71 for ; Tue, 1 Sep 2009 12:15:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=py4ZKcYi6igd8/AUWF2TXt1yVA4wLWqoFj/Qp2wN1e8ay7d2x5rB0Is/vX4KDlmO; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.51.212] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MiYdY-0005og-0F for agentx@ietf.org; Tue, 01 Sep 2009 15:03:24 -0400 Message-ID: <007801ca2a6e$2bc23f00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <1251623843.6043.6.camel@sara.home><8a0268750908301048i2b4a477dod97e582238098bbe@mail.gmail.com><1251668476.3736.14.camel@sara.home><8a0268750908301523o390d9ff1kc951bfb24d49c9e1@mail.gmail.com> <1251750777.5149.52.camel@sara.home> Date: Mon, 31 Aug 2009 12:06:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9a7e9e1b187221c911018c22155847ecf350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.51.212 Subject: Re: [Agentx] Empty context in rfc2742 X-BeenThere: agentx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SNMP Agent Extensibility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:15:39 -0000 Hi - > From: "Magnus Fromreide" > To: "Mark Ellison" > Cc: > Sent: Monday, August 31, 2009 1:32 PM > Subject: Re: [Agentx] Empty context in rfc2742 ... > While this is true it is also true that the agent is free to map the > AgentX-contexts to SNMP-contexts however it wish so I think this impose > no limits on the values of AgentX-contexts. This would be an incredibly bad idea. Perhaps section 6.1.1 of RFC 2741 could be more explicit, but to my knowledge no one has ever come to a different conclusion in deciding how to implement this. Furthermore, 6.1.1 of RFC 2741 says: If the NON_DEFAULT_CONTEXT bit in the AgentX header field h.flags is clear, then there is no context field in the PDU, and the operation refers to the default context. (This does not mean there is a zero- length Octet String, it means there is no Octet String present.) If the NON_DEFAULT_CONTEXT bit is set, then a context field immediately follows the AgentX header, and the operation refers to that specific context. The context is represented as an Octet String. There are no constraints on its length or contents. What does this mean? It means that there happen to be two ways to encode the default context. (1) set the NON_DEFAULT_CONTEXT bit to 0, and omit the context field which would otherwise immediately follow. (2) set the NON_DEFAULT_CONTEXT bit to 1, and follow it with the properly encoded zero-length string. Obviously, (2) is not encouraged, since (1) provides a more efficient encoding and we all know how parsimonious AgentX encodings are. :-) > This question is only regarding the _values_ of the agentxRegContext > column. > > As I said above it believe that agentxRegContext should represent the > values of the AgentX-context for all AgentX-registrations that is made > on the AgentX-side of the master agent. > > The problem is that the value set for AgentX-context contains one > element more than the value set for OCTET STRING. No, it doesn't. It merely provides two ways of encoding the zero-length string, used to represent the default context. > I am asking how the AgentX-context value that don't fit into the mapping > from AgentX-context to agentxRegContext should be handled. > > EXAMPLE: > > Assume that two AgentX registrations are made to a master agent that > implements rfc 2741 and rfc 2742. > > 1: { r.flags = 0, , ... } > 2: { r.flags = NON_DEFAULT_CONTEXT, r.context = "", ... } > > Now as I read 2742 the value of the agentxRegContext column for > registration #1 is "" > > The question is what the value of the agentxRegContext column for > registration #2 should be? Exactly the same. These are two attempts to register for the same context. I seem to recall a long-ago discussion about whether the latter should be treated as a protocol error. I don't recall the outcome of that discussion. As an implementor, my inclination would be to accept it, but never generate it. Randy From magfr@lysator.liu.se Tue Sep 1 15:40:26 2009 Return-Path: X-Original-To: agentx@core3.amsl.com Delivered-To: agentx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43BFA28C68B for ; Tue, 1 Sep 2009 15:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWErSx-OudNk for ; Tue, 1 Sep 2009 15:40:25 -0700 (PDT) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by core3.amsl.com (Postfix) with ESMTP id 2518C3A6C55 for ; Tue, 1 Sep 2009 15:40:25 -0700 (PDT) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 3D65340003; Wed, 2 Sep 2009 00:39:56 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 3105F40011; Wed, 2 Sep 2009 00:39:56 +0200 (CEST) Received: from [83.252.226.253] (c83-252-226-253.bredband.comhem.se [83.252.226.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id D1DDE40003; Wed, 2 Sep 2009 00:39:55 +0200 (CEST) From: Magnus Fromreide To: Randy Presuhn In-Reply-To: <007801ca2a6e$2bc23f00$6801a8c0@oemcomputer> References: <1251623843.6043.6.camel@sara.home> <8a0268750908301048i2b4a477dod97e582238098bbe@mail.gmail.com> <1251668476.3736.14.camel@sara.home> <8a0268750908301523o390d9ff1kc951bfb24d49c9e1@mail.gmail.com> <1251750777.5149.52.camel@sara.home> <007801ca2a6e$2bc23f00$6801a8c0@oemcomputer> Content-Type: text/plain Date: Wed, 02 Sep 2009 00:40:31 +0200 Message-Id: <1251844831.3745.13.camel@sara.home> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: agentx@ietf.org Subject: Re: [Agentx] Empty context in rfc2742 X-BeenThere: agentx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SNMP Agent Extensibility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 22:40:26 -0000 On Mon, 2009-08-31 at 12:06 -0700, Randy Presuhn wrote: > Hi - > > > From: "Magnus Fromreide" > > To: "Mark Ellison" > > Cc: > > Sent: Monday, August 31, 2009 1:32 PM > > Subject: Re: [Agentx] Empty context in rfc2742 > ... > > While this is true it is also true that the agent is free to map the > > AgentX-contexts to SNMP-contexts however it wish so I think this impose > > no limits on the values of AgentX-contexts. > > This would be an incredibly bad idea. Perhaps section 6.1.1 of RFC 2741 > could be more explicit, but to my knowledge no one has ever come to a > different conclusion in deciding how to implement this. Oh well, my mind must be twisted. I would probably have treated the default context as the default value for all contexts and then each distinct context would override it but I haven't given the consequences of that much thought. Now I am aware of the intended way. > Furthermore, 6.1.1 of RFC 2741 says: > If the NON_DEFAULT_CONTEXT bit in the AgentX header field h.flags is > clear, then there is no context field in the PDU, and the operation > refers to the default context. (This does not mean there is a zero- > length Octet String, it means there is no Octet String present.) If > the NON_DEFAULT_CONTEXT bit is set, then a context field immediately > follows the AgentX header, and the operation refers to that specific > context. The context is represented as an Octet String. There are > no constraints on its length or contents. > > What does this mean? It means that there happen to be two ways > to encode the default context. > (1) set the NON_DEFAULT_CONTEXT bit to 0, and omit the > context field which would otherwise immediately follow. > (2) set the NON_DEFAULT_CONTEXT bit to 1, and follow it > with the properly encoded zero-length string. > > Obviously, (2) is not encouraged, since (1) provides a more efficient > encoding and we all know how parsimonious AgentX encodings are. :-) Well, from the discussion I think it is obvious that I think that could be stated clearer. Thanks for your patience. > > > > EXAMPLE: > > > > Assume that two AgentX registrations are made to a master agent that > > implements rfc 2741 and rfc 2742. > > > > 1: { r.flags = 0, , ... } > > 2: { r.flags = NON_DEFAULT_CONTEXT, r.context = "", ... } > > > > Now as I read 2742 the value of the agentxRegContext column for > > registration #1 is "" > > > > The question is what the value of the agentxRegContext column for > > registration #2 should be? > > Exactly the same. These are two attempts to register for the same > context. > > I seem to recall a long-ago discussion about whether the latter should > be treated as a protocol error. I don't recall the outcome of that discussion. > As an implementor, my inclination would be to accept it, but never generate it. I would prefer to generate an error in order to make for a less forgiving protocol so that errors are caught earlier and the protocol is kept smaller but I know that is against the "be lenient in what you accept" motto. /MF From randy_presuhn@mindspring.com Wed Sep 9 12:19:06 2009 Return-Path: X-Original-To: agentx@core3.amsl.com Delivered-To: agentx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32E383A6943; Wed, 9 Sep 2009 12:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.032 X-Spam-Level: * X-Spam-Status: No, score=1.032 tagged_above=-999 required=5 tests=[AWL=-1.188, BAYES_50=0.001, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgKPi5Eu07Qg; Wed, 9 Sep 2009 12:19:05 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 4A9A23A68AF; Wed, 9 Sep 2009 12:19:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=pFbjliQsUn21Z/1gmq2S+2YpR64Grx7+I2yQpP1mGnPAgfkz0ozK3yvVxYA+DheX; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.33.94.93] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MlShb-0005uR-4Q; Wed, 09 Sep 2009 15:19:35 -0400 Message-ID: <006c01ca3182$7bb2b7e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" , "Disman" , Date: Wed, 9 Sep 2009 12:19:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9fdc6dc72524febf700bc4c17ecf57d5b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.94.93 Subject: [Agentx] nomcom X-BeenThere: agentx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SNMP Agent Extensibility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 19:19:06 -0000 Hi - Nomcom is still looking for people. Please see http://www.ietf.org/mail-archive/web/ietf-announce/current/msg06510.html Randy From randy_presuhn@mindspring.com Wed Sep 9 13:05:21 2009 Return-Path: X-Original-To: agentx@core3.amsl.com Delivered-To: agentx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AEC128B797; Wed, 9 Sep 2009 13:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[AWL=1.459, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRK7NQ9dd1Pu; Wed, 9 Sep 2009 13:05:20 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 781B23A6963; Wed, 9 Sep 2009 13:05:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=g9SqiXLyLcfllbQMJ+YTVUmCzstxDC5q7gFpxz8U+c4YSPzZc42AaUfj35wkzl5W; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.33.94.93] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MlTQN-0002fb-Ck; Wed, 09 Sep 2009 16:05:51 -0400 Message-ID: <000401ca3188$f3f4cb20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: , "Disman" , "LTRU Working Group" Date: Wed, 9 Sep 2009 13:05:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f95335002d8bdbe8996a78cebe1d3c87a8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.94.93 Subject: [Agentx] Fw: IESG Statement on Copyright X-BeenThere: agentx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SNMP Agent Extensibility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 20:05:21 -0000 Hi - Fwd FYI. Randy ----- Original Message ----- > From: "IESG Secretary" > To: > Cc: ; > Sent: Wednesday, September 09, 2009 12:45 PM > Subject: IESG Statement on Copyright > > This IESG Statement obsoletes all earlier IESG Statements regarding > Copyright statements in MIB and PIB Modules. > > The IESG is providing this guidance to align current practice with > RFC 5377, RFC 5378, and the resulting IETF Trust Legal Provisions (TLP) > (http://trustee.ietf.org/license-info). > > IETF Contributions and IETF Documents often include code components > that are intended to be directly processed by a computer. Examples of > such code components include ABNF definitions, XML Schemas, XML DTDs, > XML RelaxNG definitions, tables of values, MIBs, PIBs, ASN.1, and > classical programming source code. The IETF Trust maintains a list of > code component types. A link to this list can be found on this web > page: http://trustee.ietf.org/license-info. > > In addition to the code component types listed, any text found between > the markers <CODE BEGINS> and <CODE ENDS> shall be considered > a code component. Authors may wish to use these markers as clear > delimiters of code components. > > Authors are encouraged to collect code into a separate section or > appendix. > > The TLP requires copyright notice in IETF Documents, but not necessarily > in each code component within an IETF Document. Authors may choose to > include a copyright notice as a comment when a significant amount of > code is collected together. For example, authors may include a > copyright notice in a comment as part of an ASN.1 module or a > representation of a classical programming language file. If IETF > Document authors choose to include a code component copyright notice > comment, they must follow the guidance in Section 6.d of the TLP. > Implementors that extract any code component from the IETF Document must > include the BSD license text as described in Section 4.e of the TLP.