From randy_presuhn@mindspring.com Tue Aug 25 19:15:17 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 5D32928C2F9; Tue, 25 Aug 2009 19:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 2v-0TWujg--z; Tue, 25 Aug 2009 19:15:16 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id BEB3528C2EC; Tue, 25 Aug 2009 19:15:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=kocfBLH7AK9dJBHVRjvN0ke9s7WnhkaydBojJGgGXNdb4dSma/ggWjo7+grIBBQ4; 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.23.160.233] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Mg82j-0001Ln-Oq; Tue, 25 Aug 2009 22:15:22 -0400 Message-ID: <00a701ca25f3$79deb6c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: , "Disman" , "LTRU Working Group" Date: Tue, 25 Aug 2009 19:18:15 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f944b50984107aa2caf0f03f3501b633bb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.160.233 Subject: [Agentx] Fw: 76th IETF - WG/BOF Scheduling 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, 26 Aug 2009 02:15:17 -0000 Hi - Forwarded for your information. Randy ----- Original Message ----- > From: "IETF Agenda" > To: "Working Group Chairs" > Cc: ; > Sent: Tuesday, August 18, 2009 12:57 PM > Subject: 76th IETF - WG/BOF Scheduling > > Subject: 76th IETF - Working Group/BOF Scheduling > > ----------------------------------------------------------------- > 76th IETF Hiroshima, Japan > Meeting Dates: November 8-13, 2009 > Host: WIDE > ----------------------------------------------------------------- > IETF meetings start Monday morning and run through Friday mid-afternoon > (15:15). > > We are accepting scheduling requests for all Working Groups and BOFs > starting today. The milestones and deadlines for scheduling-related > activities are as follows: > > NOTE: cutoff dates are subject to change. > > - 2009-09-07 (Monday): Cutoff date for BOF proposal requests to Area > Directors at 17:00 PDT (24:00 UTC/GMT). To request a BOF, please see > instructions on Requesting a BOF. > - 2009-09-14 (Monday): Cutoff date for requests to schedule Working Group > meetings at 17:00 PDT (24:00 UTC/GMT). To request a Working Group session, > use the IETF Meeting Session Request Tool. ** Please note - if you send in > your request after this date your Working Group will not be scheduled > until after the Preliminary agenda has been published (Friday, - October > 2, 2009) and will NOT receive priority scheduling. ** > - 2009-09-14 (Monday): Cutoff date for Area Directors to approve BOFs at > 17:00 PDT (24:00 UTC/GMT). > - 2009-10-02 (Friday): Preliminary agenda published for comment. > - 2009-10-09 (Friday): Cutoff date for requests to reschedule Working > Group and BOF meetings 17:00 PDT (24:00 UTC/GMT). > - 2009-10-16 (Monday): Final agenda to be published. > - 2009-10-28 (Wednesday): Draft Working Group agendas due by 17:00 PDT > (24:00 UTC/GMT), upload using IETF Meeting Materials Management Tool. > - 2009-11-02 (Monday): Revised Working Group agendas due by 17:00 PST > (01:00 Tuesday, November 3 UTC/GMT), upload using IETF Meeting Materials > Management Tool. > > Submitting Requests for Working Group and BOF Sessions > > Please submit requests to schedule your Working Group sessions using the > "IETF Meeting Session Request Tool," a Web-based tool for submitting all > of the information that the Secretariat requires to schedule your > sessions. > > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > Please send requests to schedule your BOF sessions to agenda@ietf.org. > Please include the acronym of your BOF in the subject line of the message, > and include all of the information specified in item (4) of "Requesting > Meeting Sessions at IETF Meetings" in the body. (This document is > included below.) > > Submitting Session Agendas > > For the convenience of meeting attendees, we ask that you submit the > agendas for your Working Group sessions as early as possible. Draft > Working Group agendas are due Wednesday, October 28 by 17:00 PDT (24:00 > UTC/GMT). Revised Working Group agendas are due no later than Monday, > November 2 at 17:00 PDT (01:00 Tuesday, November 3 UTC/GMT). The proposed > agenda for a BOF session should be submitted along with your request for a > session. Please be sure to copy your Area Director on that message. > > Please submit the agendas for your Working Group sessions using the "IETF > Meeting Materials Management Tool," a Web-based tool for making your > meeting agenda, minutes, and presentation slides available to the > community before, during, and after an IETF meeting. If you are a BOF > chair, then you may use the tool to submit a revised agenda as well as > other materials for your BOF once the BOF has been approved. > > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi > > Additional information about this tool is available at: > > http://www.ietf.org/instructions/meeting_materials_tool.html > > Agendas submitted via the tool will be available to the public on the > "IETF Meeting Materials" Web page as soon as they are submitted. > > The URL for the "IETF 76 Meeting Materials" Web page is: > > https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=76 > > If you are a Working Group chair, then you already have accounts on the > "IETF Meeting Session Request Tool" and the "IETF Meeting Materials > Management Tool." The same User ID and password will work for both tools. > If you are a BOF chair who is not also a Working Group chair, then you > will be given an account on the "IETF Meeting Materials Management Tool" > when your BOF has been approved. If you require assistance in using > either tool, or wish to report a bug, then please send a message to: > ietf-action@ietf.org. > =============================================================== > For your convenience, comprehensive information on requesting meeting > sessions at IETF 76 is presented below: > > 1. Requests to schedule Working Group sessions should be submitted using > the "IETF Meeting Session Request Tool," a Web-based tool for submitting > all of the information required by the Secretariat to schedule your > sessions. The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > If you require an account on this tool, or assistance in using it, then > please send a message to ietf-action@ietf.org. If you are unable to use > the tool, then you may send your request via e-mail to agenda@ietf.org, > with a copy to the appropriate Area Director(s). > > Requests to schedule BOF sessions must be sent to agenda@ietf.org with a > copy to the appropriate Area Director(s). > > When submitting a Working Group or BOF session request by e-mail, please > include the Working Group or BOF acronym in the Subject line. > > 2. BOFs will NOT be scheduled unless the Area Director(s) approved > request is accompanied by a BOF'S FULL NAME AND ACRONYM, AREA, CHAIR(S) > NAME(S) (given together with e-mail address(es)), AN AGENDA AND FULL > DESCRIPTION, and the information requested in (4) below. (Please read the > BOF Procedure at: http://www.ietf.org/ietf/1bof-procedures.txt before > requesting a session for a BOF.) > > 3. A Working Group may request either one or two sessions. If your > Working Group requires more than two sessions, then your request must be > approved by an Area Director. Additional sessions will be assigned, based > on availability, after Friday, October 9 at 17:00 PDT (24:00 UTC/GMT), the > cut-off date for requests to reschedule a session. > > 4. You MUST provide the following information before a Working Group or > BOF session will be scheduled: > > a. Working Group or BOF full name with acronym in brackets: > > b. AREA under which Working Group or BOF appears: > > c. CONFLICTS you wish to avoid, please be as specific as possible: > > d. Expected Attendance (figures from the 75th IETF meeting are > included at the end of this message): > > e. Special requests: > > f. Number of sessions: > > g. Length of session: > - 1 hour > - 1 1/2 hours > - 2 hours > - 2 1/2 hours > > For more information on scheduling Working Group and BOF sessions, please > refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures" > (http://www.ietf.org/rfc/rfc2418.txt). > =============================================================== > For your convenience please find here a list of the IETF Area Directors > with their e-mail addresses: > > IETF Chair > Russ Housley > > Applications Area (app) > Lisa Dusseault > Alexey Melnikov > > Internet Area (int) > Jari Arkko > Ralph Droms > > Operations & Management Area (ops) > Ronald Bonica > Dan Romascanu > > Real-time Applications and Infrastructure Area (rai) > Cullen Jennings > Robert Sparks > > Routing Area (rtg) > Ross Callon > Adrian Farrel > > Security Area (sec) > Pasi Eronen > Tim Polk > > Transport Area (tsv) > Lars Eggert > Magnus Westerlund > =========================================================== > 75th IETF Meeting Attendance Number > > 6lowpan 50 > 6man 80 > alto 86 > ancp 27 > apparea (AG) 72 > autoconf 48 > avt 73 > avt (2nd session) 34 > behave 141 > behave (2nd session) 126 > bliss 54 > bmwg 24 > capwap 7 > ccamp 89 > codec-BOF 152 > dhc 42 > dime 18 > dispatch 83 > dispatch (2nd session) 24 > dkim 25 > dnsext 113 > dnsop 171 > drinks 51 > dtnrg 50 > eai 35 > ecrit 61 > emu 32 > fecframe 16 > forces 25 > geopriv 62 > grow 88 > hip 66 > hiprg 33 > hokey 38 > hokey (2nd session) 27 > httpbis 25 > iccrg 54 > idnabis 81 > idr 92 > intarea 142 > ipdvb 5 > ipfix 28 > ippm 26 > ipsecme 43 > isis 25 > isms 21 > keyprov 25 > kitten 17 > krb-wg 13 > l2vpn 100 > l3vpn 101 > ledbat 58 > lisp 148 > manet 43 > mboned 39 > mediactrl 22 > mext 61 > mif 84 > mip4 29 > mmusic 58 > morg 14 > mpls 154 > mpls (2nd session) 133 > mptcp-BOF 126 > multimob-BOF 42 > nea 35 > netconf 27 > netext 56 > netext2-BOF 69 > netmod 32 > netmod (2nd session) 20 > nfsv4 15 > ogpx-BOF 54 > opsarea 72 > opsawg 33 > ospf 38 > p2prg 88 > p2psip 81 > pce 52 > pcn 31 > pim 41 > pkix 42 > pwe3 136 > radext 22 > rmt 11 > roll 80 > rrg 94 > rtgarea 131 > rtgwg 42 > saag 80 > sasl 22 > savi NO SHEETS > sidr 95 > sieve 11 > simple 69 > sipcore 72 > softwire 103 > speermint NO SHEETS > syslog 24 > tcpm 44 > tictoc 47 > tls 36 > tsvarea 98 > tsvwg 55 > v6ops 155 > vcarddav 19 > xcon 22 > xmpp 44 > yam 19 > From magfr@lysator.liu.se Sun Aug 30 02:17:20 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 7D9C93A6A6B for ; Sun, 30 Aug 2009 02:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_SE=0.35] 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 vpU7TM-D7qu0 for ; Sun, 30 Aug 2009 02:17:19 -0700 (PDT) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by core3.amsl.com (Postfix) with ESMTP id B0B983A6A5D for ; Sun, 30 Aug 2009 02:17:19 -0700 (PDT) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 838064004B for ; Sun, 30 Aug 2009 11:16:48 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 7815840058; Sun, 30 Aug 2009 11:16:48 +0200 (CEST) Received: from [83.252.237.134] (c83-252-237-134.bredband.comhem.se [83.252.237.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 1FC014004B for ; Sun, 30 Aug 2009 11:16:48 +0200 (CEST) From: Magnus Fromreide To: agentx@ietf.org Content-Type: text/plain Date: Sun, 30 Aug 2009 11:17:23 +0200 Message-Id: <1251623843.6043.6.camel@sara.home> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: [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: Sun, 30 Aug 2009 09:17:20 -0000 Hello. According to rfc2742 agentxRegContext (octet string) is "The context in which the session supports the objects in this region. A zero-length context indicates the default context. " Now I am would like to know how a zero-length context should be represented? /MF From mark@ellisonsoftware.com Sun Aug 30 10:48:30 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 7AF263A6A8D for ; Sun, 30 Aug 2009 10:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 wpsOmlXs5hLH for ; Sun, 30 Aug 2009 10:48:29 -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 5B9893A682F for ; Sun, 30 Aug 2009 10:48:29 -0700 (PDT) Received: by ywh4 with SMTP id 4so6895205ywh.17 for ; Sun, 30 Aug 2009 10:48:34 -0700 (PDT) MIME-Version: 1.0 Sender: mark@ellisonsoftware.com Received: by 10.150.61.18 with SMTP id j18mr5928956yba.173.1251654514670; Sun, 30 Aug 2009 10:48:34 -0700 (PDT) In-Reply-To: <1251623843.6043.6.camel@sara.home> References: <1251623843.6043.6.camel@sara.home> Date: Sun, 30 Aug 2009 13:48:34 -0400 X-Google-Sender-Auth: 2f40d4508d66ee7a Message-ID: <8a0268750908301048i2b4a477dod97e582238098bbe@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: Sun, 30 Aug 2009 17:48:30 -0000 On Sun, Aug 30, 2009 at 5:17 AM, Magnus Fromreide wrote: > Hello. > > According to rfc2742 agentxRegContext (octet string) is > "The context in which the session supports the objects in this > region. A zero-length context indicates the default context. > " > > Now I am would like to know how a zero-length context should be > represented? > The default context is an OCTET STRING of zero-length. How to represent this depends upon where it is being represented. On the wire, the tag is "OCTET STRING" the length is zero(0) and the value occupies no octets. There are numerous examples of OCTET STRINGs that may be zero-length in IETF standard MIB modules. For example, in the UsmUserTable, the usmUserPublic may be a zero-length string. In the USM MIB module, tthe usmUserPublic object definition shows he zero-length string as represented by the DEFVAL clause: { ''H } -- the empty string. A zero-length string and the empty-string are synonymous. - Mark http://EllisonSoftware.com From magfr@lysator.liu.se Sun Aug 30 14:41:13 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 C7F053A6B93 for ; Sun, 30 Aug 2009 14:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.042 X-Spam-Level: X-Spam-Status: No, score=-1.042 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 GZ6C0-ZAQ7UT for ; Sun, 30 Aug 2009 14:41:13 -0700 (PDT) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by core3.amsl.com (Postfix) with ESMTP id 880173A6909 for ; Sun, 30 Aug 2009 14:41:12 -0700 (PDT) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id B905240028; Sun, 30 Aug 2009 23:40:42 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id ACA704003A; Sun, 30 Aug 2009 23:40:42 +0200 (CEST) Received: from [83.252.235.163] (c83-252-235-163.bredband.comhem.se [83.252.235.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 567B340028; Sun, 30 Aug 2009 23:40:42 +0200 (CEST) From: Magnus Fromreide To: Mark Ellison In-Reply-To: <8a0268750908301048i2b4a477dod97e582238098bbe@mail.gmail.com> References: <1251623843.6043.6.camel@sara.home> <8a0268750908301048i2b4a477dod97e582238098bbe@mail.gmail.com> Content-Type: text/plain; charset="ISO-8859-1" Date: Sun, 30 Aug 2009 23:41:16 +0200 Message-Id: <1251668476.3736.14.camel@sara.home> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 8bit 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: Sun, 30 Aug 2009 21:41:14 -0000 On Sun, 2009-08-30 at 13:48 -0400, Mark Ellison wrote: > On Sun, Aug 30, 2009 at 5:17 AM, Magnus Fromreide wrote: > > Hello. > > > > According to rfc2742 agentxRegContext (octet string) is > > "The context in which the session supports the objects in this > > region. A zero-length context indicates the default context. > > " > > > > Now I am would like to know how a zero-length context should be > > represented? > > > The default context is an OCTET STRING of zero-length. Not according to RFC 2741 6.1.1 §4. In agentxRegContext we are looking a AgentX registrations and in this domain it is explicitly stated that NON_DEFAULT_CONTEXT "" is distinct from DEFAULT_CONTEXT but I can see no provision for the MIB to represent that. > How to represent this depends upon where it is being represented. > > On the wire, the tag is "OCTET STRING" the length is zero(0) and the > value occupies no octets. There are numerous examples of OCTET > STRINGs that may be zero-length in IETF standard MIB modules. > > For example, in the UsmUserTable, the usmUserPublic may be a > zero-length string. In the USM MIB module, tthe usmUserPublic object > definition shows he zero-length string as represented by the DEFVAL > clause: { ''H } -- the empty string. > > A zero-length string and the empty-string are synonymous. This is about the specific case of AgentX - we are talking about a zero-length string and a non-existing string. > - Mark > http://EllisonSoftware.com From mark@ellisonsoftware.com Sun Aug 30 15:23:20 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 7C2833A6D07 for ; Sun, 30 Aug 2009 15:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.917 X-Spam-Level: X-Spam-Status: No, score=-101.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 NDaDRvM24Tym for ; Sun, 30 Aug 2009 15:23:19 -0700 (PDT) Received: from mail-gx0-f226.google.com (mail-gx0-f226.google.com [209.85.217.226]) by core3.amsl.com (Postfix) with ESMTP id 7EEC23A6A2A for ; Sun, 30 Aug 2009 15:23:19 -0700 (PDT) Received: by gxk26 with SMTP id 26so1988530gxk.18 for ; Sun, 30 Aug 2009 15:23:26 -0700 (PDT) MIME-Version: 1.0 Sender: mark@ellisonsoftware.com Received: by 10.151.28.10 with SMTP id f10mr7643485ybj.71.1251671006441; Sun, 30 Aug 2009 15:23:26 -0700 (PDT) In-Reply-To: <1251668476.3736.14.camel@sara.home> References: <1251623843.6043.6.camel@sara.home> <8a0268750908301048i2b4a477dod97e582238098bbe@mail.gmail.com> <1251668476.3736.14.camel@sara.home> Date: Sun, 30 Aug 2009 18:23:26 -0400 X-Google-Sender-Auth: 571939c3c6f63cb4 Message-ID: <8a0268750908301523o390d9ff1kc951bfb24d49c9e1@mail.gmail.com> From: Mark Ellison To: Magnus Fromreide Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Sun, 30 Aug 2009 22:23:20 -0000 Hi Magnus- On Sun, Aug 30, 2009 at 5:41 PM, Magnus Fromreide wro= te: > On Sun, 2009-08-30 at 13:48 -0400, Mark Ellison wrote: >> On Sun, Aug 30, 2009 at 5:17 AM, Magnus Fromreide = wrote: >> > Hello. >> > >> > According to rfc2742 agentxRegContext (octet string) is >> > =A0 =A0 "The context in which the session supports the objects in this >> > =A0 =A0 =A0region. =A0A zero-length context indicates the default cont= ext. >> > =A0 =A0 " >> > >> > Now I am would like to know how a zero-length context should be >> > represented? >> > >> The default context is an OCTET STRING of zero-length. > > Not according to RFC 2741 6.1.1 =A74. > > In agentxRegContext we are looking a AgentX registrations and in this > domain it is explicitly stated that NON_DEFAULT_CONTEXT "" is distinct > from DEFAULT_CONTEXT but I can see no provision for the MIB to represent > that. Thanks for this reference- your original question was in regard to RFC 2742. As the agentxRegContext object-type definition states, "A zero-length context indicates the default context". I believe this is consistent with my previous reply. The 2741 section cited above applies to the AgentX header. Effectively, for 2742 you won't have a zero-length context name for a non default context. In the SNMP, the AgentX context is mapped from the SNMPv3 contextName in the scoped PDU (most current is 3411 sxn 3.3.3). Since every contextName within an SNMP entity MUST be unique there can not be both the default context and a non default context with a zero-length string. > >> How to represent this depends upon where it is being represented. >> >> On the wire, the tag is "OCTET STRING" the length is zero(0) and the >> value occupies no octets. =A0There are numerous examples of OCTET >> STRINGs that may be zero-length in IETF standard MIB modules. >> >> For example, in the UsmUserTable, the usmUserPublic may be a >> zero-length string. =A0In the USM MIB module, tthe usmUserPublic object >> definition shows he zero-length string as represented by the DEFVAL >> clause: =A0{ ''H } =A0-- the empty string. >> >> A zero-length string and the empty-string are synonymous. > > This is about the specific case of AgentX - we are talking about a > zero-length string and a non-existing string. > >> - Mark >> http://EllisonSoftware.com > From magfr@lysator.liu.se Mon Aug 31 13:32:55 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 6A6A428C2A2 for ; Mon, 31 Aug 2009 13:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.046 X-Spam-Level: X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=0.003, 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 SdjiCzX6U41U for ; Mon, 31 Aug 2009 13:32:54 -0700 (PDT) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by core3.amsl.com (Postfix) with ESMTP id 261053A6EE2 for ; Mon, 31 Aug 2009 13:32:53 -0700 (PDT) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 9D083400C4; Mon, 31 Aug 2009 22:32:26 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 90B67400C7; Mon, 31 Aug 2009 22:32:26 +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 AB236400C4; Mon, 31 Aug 2009 22:32:25 +0200 (CEST) From: Magnus Fromreide To: Mark Ellison In-Reply-To: <8a0268750908301523o390d9ff1kc951bfb24d49c9e1@mail.gmail.com> References: <1251623843.6043.6.camel@sara.home> <8a0268750908301048i2b4a477dod97e582238098bbe@mail.gmail.com> <1251668476.3736.14.camel@sara.home> <8a0268750908301523o390d9ff1kc951bfb24d49c9e1@mail.gmail.com> Content-Type: text/plain; charset="ISO-8859-1" Date: Mon, 31 Aug 2009 22:32:57 +0200 Message-Id: <1251750777.5149.52.camel@sara.home> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 8bit 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: Mon, 31 Aug 2009 20:32:55 -0000 On Sun, 2009-08-30 at 18:23 -0400, Mark Ellison wrote: > Hi Magnus- Hello Mark. > On Sun, Aug 30, 2009 at 5:41 PM, Magnus Fromreide wrote: > > On Sun, 2009-08-30 at 13:48 -0400, Mark Ellison wrote: > >> On Sun, Aug 30, 2009 at 5:17 AM, Magnus Fromreide wrote: > >> > Hello. > >> > > >> > According to rfc2742 agentxRegContext (octet string) is > >> > "The context in which the session supports the objects in this > >> > region. A zero-length context indicates the default context. > >> > " > >> > > >> > Now I am would like to know how a zero-length context should be > >> > represented? > >> > > >> The default context is an OCTET STRING of zero-length. > > > > Not according to RFC 2741 6.1.1 §4. > > > > In agentxRegContext we are looking a AgentX registrations and in this > > domain it is explicitly stated that NON_DEFAULT_CONTEXT "" is distinct > > from DEFAULT_CONTEXT but I can see no provision for the MIB to represent > > that. > > Thanks for this reference- your original question was in regard to RFC > 2742. Well, they are somewhat related since 2742 has no purpose without 2741. > As the agentxRegContext object-type definition states, "A > zero-length context indicates the default context". I believe this is > consistent with my previous reply. I fear that we are speaking past each other and will do one last attempt to ask my question. > The 2741 section cited above applies to the AgentX header. > Effectively, for 2742 you won't have a zero-length context name for a > non default context. 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. > In the SNMP, the AgentX context is mapped from the SNMPv3 contextName > in the scoped PDU (most current is 3411 sxn 3.3.3). Since every > contextName within an SNMP entity MUST be unique there can not be both > the default context and a non default context with a zero-length > string. 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 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. 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? /MF