From mailman-admin@ietf.org Sat Mar 1 12:51:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13101 for ; Sat, 1 Mar 2003 12:51:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21I0mp06636 for ; Sat, 1 Mar 2003 13:00:48 -0500 Date: Sat, 01 Mar 2003 13:00:48 -0500 Message-ID: <20030301180048.26394.3662.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: disman-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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, disman-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 All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for disman-archive@lists.ietf.org: List Password // URL ---- -------- disman@ietf.org hixour https://www1.ietf.org/mailman/options/disman/disman-archive%40lists.ietf.org From mailnull@www1.ietf.org Wed Mar 12 19:20:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01219 for ; Wed, 12 Mar 2003 19:20:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2D0YN029399 for disman-archive@odin.ietf.org; Wed, 12 Mar 2003 19:34:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D0YNO29393 for ; Wed, 12 Mar 2003 19:34:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01198 for ; Wed, 12 Mar 2003 19:19:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D0XVO29362; Wed, 12 Mar 2003 19:33:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D0WxO29344 for ; Wed, 12 Mar 2003 19:32:59 -0500 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01162 for ; Wed, 12 Mar 2003 19:18:17 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2D0KPEY005237 for ; Wed, 12 Mar 2003 16:20:25 -0800 (PST) Received: from cisco.com (dhcp-128-107-166-145.cisco.com [128.107.166.145]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEX57585; Wed, 12 Mar 2003 16:15:07 -0800 (PST) Message-ID: <3E6FCEC8.D805B654@cisco.com> From: Ramanathan Kavasseri X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: disman@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Disman] So does anyone use the EVENT/EXPRESSION/NOTIF-LOG mibs? Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Mar 2003 16:20:24 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Does any vendor have customer deployment reports for the EVENT, EXPRESSION and NOTIF-LOG mibs? Or any implementation reports? Cisco's implemented all three, but I've not been able to find any deployment from customers... Ram Kavasseri From mailnull@www1.ietf.org Fri Mar 14 14:12:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09020 for ; Fri, 14 Mar 2003 14:12:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EJRUa01968 for disman-archive@odin.ietf.org; Fri, 14 Mar 2003 14:27:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJRUO01965 for ; Fri, 14 Mar 2003 14:27:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08961 for ; Fri, 14 Mar 2003 14:11:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJQpO01917; Fri, 14 Mar 2003 14:26:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJPXO01828 for ; Fri, 14 Mar 2003 14:25:33 -0500 Received: from seymour39.snmp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08853 for ; Fri, 14 Mar 2003 14:09:59 -0500 (EST) Received: from snowball.snmp.com (snowball.snmp.com [192.147.142.193]) by seymour39.snmp.com (8.9.3/m.030206) with ESMTP id OAA17573 for ; Fri, 14 Mar 2003 14:12:08 -0500 (EST) Received: from snowball (moulton@localhost) by snowball.snmp.com (8.11.2/8.11.2/snmpclient.mc-011018) with ESMTP id h2EJC8C14031 for ; Fri, 14 Mar 2003 14:12:08 -0500 Message-Id: <200303141912.h2EJC8C14031@snowball.snmp.com> X-Mailer: exmh version 2.6.1 02/18/2003 with nmh-1.0.4 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: B To: disman@ietf.org Subject: Re: [Disman] So does anyone use the EVENT/EXPRESSION/NOTIF-LOG mibs? In-reply-to: Your message of Wed, 12 Mar 2003 16:20:24 -0800. <3E6FCEC8.D805B654@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: Steve Moulton Content-Transfer-Encoding: 8bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 14 Mar 2003 14:12:08 -0500 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit SNMP Research has developed and deployed the EVENT MIB. On Wednesday, March 12 2003, Ramanathan Kavasseri wrote: > Does any vendor have customer deployment reports for the > EVENT, EXPRESSION and NOTIF-LOG mibs? > > Or any implementation reports? > > Cisco's implemented all three, but I've not been able > to find any deployment from customers... --- Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 moulton@snmp.com Knoxville, TN 37920-9716 USA http://www.snmp.com From mailnull@www1.ietf.org Fri Mar 14 15:56:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14028 for ; Fri, 14 Mar 2003 15:56:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ELBmb10104 for disman-archive@odin.ietf.org; Fri, 14 Mar 2003 16:11:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELBmO10101 for ; Fri, 14 Mar 2003 16:11:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14022 for ; Fri, 14 Mar 2003 15:56:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELBBO10089; Fri, 14 Mar 2003 16:11:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELArO10074 for ; Fri, 14 Mar 2003 16:10:53 -0500 Received: from scaup.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14015; Fri, 14 Mar 2003 15:55:15 -0500 (EST) Received: from h-68-164-73-245.snvacaid.covad.net ([68.164.73.245] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18twF3-0006VB-00; Fri, 14 Mar 2003 12:57:26 -0800 Message-ID: <00bb01c2ea6c$c69c6120$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" Cc: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Disman] Disman WG agenda for San Francisco IETF meeting Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 14 Mar 2003 13:00:42 -0800 Hi - Here's the agenda for the disman WG meeting in San Francisco. Please let me know if there are additional topics you'd like to discuss. Randy -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Distributed Management WG (disman) Wednesday, March 19, 2003 at 15:30-17:30 =============================== CHAIR: Randy Presuhn AGENDA: 1. Administrative matters Working group charter is at http://www.ietf.org/html.charters/disman-charter.html 1.1 introductions 1.2 selection of minute-taker PLEASE read http://www.ietf.org/instructions/minutes.html volunteers PRIOR to the meeting greatly appreciated! 1.3 circulation of sign-up sheet 1.4 Review of Agenda 1.5 Allocation of time 2. Status of Current work (all charter milestones are "done") 2.1 Script MIB: RFC 3165 (Proposed Standard), advancement? 2.2 Schedule MIB: RFC 3231 (Proposed Standard), advancement? 2.3 Remote Operations MIB: RFC 2925 (Proposed Standard) Updates were to appear in - at least two implementations - some corrections / clarifications agreed - IPv6 "issues" (see ) 2.4 Expression MIB: RFC 2982 (Proposed Standard) Soliciting implementation/deployment feedback on RFC 2982. Updates in 2.5 Event MIB: RFC 2981 (Proposed Standard) Soliciting implementation/deployment feedback on RFC 2981. Updates in 2.6 Notification/Log MIB: RFC 3014 (Proposed Standard) Soliciting implementation/deployment feedback on RFC 3014. Updates in 2.7 Alarm work internet-drafts: 3. Other relevant work 3.1 ITU-T liaison statements 3.2 Exploiting eos / sming / snmpconf / netconf work 4. Charter updates. Please see http://www.ietf.org/html.charters/disman-charter.html 4.1 Set dates for completion of updates to existing work 4.1 Requests for new work? 6. Wrap-up 6.1 review of action items 6.2 reminders to minute-takers and presenters PLEASE read http://www.ietf.org/instructions/minutes.html and http://www.ietf.org/instructions/slides.html, respectively. 6.3 retrieval of sign-up sheet From mailnull@www1.ietf.org Fri Mar 14 16:13:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14664 for ; Fri, 14 Mar 2003 16:13:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ELSVH10911 for disman-archive@odin.ietf.org; Fri, 14 Mar 2003 16:28:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELSUO10908 for ; Fri, 14 Mar 2003 16:28:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14624 for ; Fri, 14 Mar 2003 16:12:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELS5O10891; Fri, 14 Mar 2003 16:28:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELRIO10840 for ; Fri, 14 Mar 2003 16:27:18 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14600 for ; Fri, 14 Mar 2003 16:11:41 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2ELDk0E017843; Fri, 14 Mar 2003 13:13:47 -0800 (PST) Received: from cisco.com (dhcp-128-107-166-145.cisco.com [128.107.166.145]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AFB12098; Fri, 14 Mar 2003 13:08:26 -0800 (PST) Message-ID: <3E724609.1A2E43F7@cisco.com> From: Ramanathan Kavasseri X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Moulton CC: disman@ietf.org Subject: Re: [Disman] So does anyone use the EVENT/EXPRESSION/NOTIF-LOG mibs? References: <200303141912.h2EJC8C14031@snowball.snmp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 14 Mar 2003 13:13:45 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Steve, thanks for the feedback. I believe there are a few vendors with EVENT-MIB implementations. Do you know of any customers in the field use this MIB for network management? Ram Steve Moulton wrote: > > SNMP Research has developed and deployed the EVENT MIB. > > On Wednesday, March 12 2003, Ramanathan Kavasseri wrote: > > > Does any vendor have customer deployment reports for the > > EVENT, EXPRESSION and NOTIF-LOG mibs? > > > > Or any implementation reports? > > > > Cisco's implemented all three, but I've not been able > > to find any deployment from customers... > > --- > Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 > Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 > moulton@snmp.com Knoxville, TN 37920-9716 USA http://www.snmp.com From mailnull@www1.ietf.org Sat Mar 15 15:38:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26014 for ; Sat, 15 Mar 2003 15:38:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2FKsSS32206 for disman-archive@odin.ietf.org; Sat, 15 Mar 2003 15:54:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FKsSO32203 for ; Sat, 15 Mar 2003 15:54:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26010 for ; Sat, 15 Mar 2003 15:38:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FKrcO32185; Sat, 15 Mar 2003 15:53:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FKqKO32135 for ; Sat, 15 Mar 2003 15:52:20 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25962 for ; Sat, 15 Mar 2003 15:36:15 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2FKcPJ09559 for ; Sat, 15 Mar 2003 15:38:25 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sat, 15 Mar 2003 21:38:21 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501271916@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Disman (E-mail) (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Disman] AD review of: draft-ietf-disman-alarm-mib-09.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Mar 2003 21:38:19 +0100 Sorry that it took so long. - New MIB boilerplate is now prefered see www.ops.ietf.org Nice thing is that it is much shorter and has far less references. - New MIB security guidelines to be followed see www.ops.ietf.org This one is a bit more elaborate than what you currently have - We want MIB COPYright in the MODULE-IDENTITY in the DESCRIPTION clause. See recent discussions on MIBS mailing list and in draft-ietf-ops-mib-review-guidelines-01.txt - Page 4, you may want to add [RFC2119] refernece to the text - In the IANA maintained IANA-ITU-ALARM-TC mib, pls add in DESCRIPTION clause the rules/guidelines for IANA on how to add/change stuff in this MIB module. Pls also add (or instruct RFC-editor to add) a (normative reference) to the iana web site where this IANA maintained MIB module will be placed. Also, add text to make it clear that this is only the initial module and that the authoritative copy to be referenced in any future document must be the one at iana web site. Not sure if this was posted anywhere yet (it should show up in our IESG minutes), but 20 Feb, IESG discussed this in their bi-weekly telechat. Here is the result: The IESG discussed if new IANA-maintained MIB modules should be published as (part of) an RFC. The consensus is that the initial version indeed is to be in an RFC. The version in that RFC MUST make sure that some statement is made that the authoritative version of the IANA-maintained MIB module is at the IANA web pages. I guess 2nd para in sect 5.2 does that. May want to add the ref to the iana web page to be - ianaItuAlarmNumbers MODULE-IDENTITY needs a REVISION clause - I prefer to see ::= { mib-2 xx} -- to be assigned by IANA That is, add the comment that IANA needs to assign a value So that IANA can clearly see where they need to do things This holds for all MIB modules. In fact, I would change this: DESCRIPTION "Initial version, published as RFC XXXX." ::= { mib-2 xx } Into DESCRIPTION "Initial version, published as RFC XXXX." -- RFC-Editor assigns XXXX ::= { mib-2 xx } -- to be assigned by IANA - When I see: ResourceId ::= TEXTUAL-CONVENTION then I wonder... is this indeed a "resourceId" in the generic sense, or have we limited it here for the ALARM-MIB type of resources? In other words, would it maybe better to name it: AlarmResourceId ::= TEXTUAL-CONVENTION This to avoid conflict with other types of Resources? - I see: alarmModelVarbindIndex OBJECT-TYPE SYNTAX Integer32 Does a negative value ever make sense? Is an Unsigned32 SYNTAX better? - I cannot find a StorageType object or any text in a DESCRIPTION clause that explains the persistency behavioru for alarmModelTable I believe this is so for more tables in this(these) MIB module(s) - I see: alarmActiveEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current DESCRIPTION "The identification of the SNMP engine at which the alarm originated. If the alarm list can contain alarms from only one engine or the alarm is from an SNMPv1 system, this object is a zero length string." But... the SnmpEngineID as specified in RFC3411 has a SIZE(5..32). So it cannot be a zero length string. What you need is a LocalSnmpEngineOrSnmpEngineID or some such. The PM-MIB in SNMPCONF WG had same problem. In rev 13, they now have: pmRoleContextEngineID OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 5..32)) Maybe this calls for a common TC ?? If not, then you can solve it in a similar way - I see: alarmActiveContextName OBJECT-TYPE SYNTAX SnmpAdminString I wonder if it would not be (much) better to do: alarmActiveContextName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) After all, a contextName can only have that size as far as I know. Or at least, we use that size in all the SNMP MIB mdoules we have created sofar. Occurs in alarmClearTable also - I see: alarmClearMaximum OBJECT-TYPE SYNTAX Integer32 Would a negative value ever make sense? - I see Underscores in the IANA-ITU-ALARM-TC mib. Formally they are not allowed. So why are we doing this? I do not see a good reason. Can we not just leave the underscore out? Maybe this was discussed on WG .. pls refresh my memory if so. - SMIlint tells me about ITU-ALARM-MIB: .\ITU-ALARM-MIB:359: warning: current group `ituAlarmServiceUserGroup' is not referenced in this module .\ITU-ALARM-MIB:369: warning: current group `ituAlarmSecurityGroup' is not referenced in this module .\ITU-ALARM-MIB:380: warning: current group `ituAlarmStatisticsGroup' is not referenced in this module Now... it is not mandatory to reference it. But see bottom of page 23 of draft-ietf-ops-mib-review-guidelines-01.txt which recommends to actually list them - SMIlint tells me about ALARM-MIB: .\ALARM-MIB:967: warning: current group `alarmActiveStatsGroup' is not referenced in this module .\ALARM-MIB:980: warning: current group `alarmClearGroup' is not referenced in this module .\ALARM-MIB:997: warning: current group `alarmNotificationsGroup' is not referenced in this module Same comments as above. - I am missing an IPR statement. - when you do an update, pls update the year for the copyrigth statements in various places. - same for dates in MIB modules. - Pls realize that RFCs that contain MIB modules from which you IMPORT anything must be referenced in a normative way. I say this, cause for example the new boilerplate no longer refrences RFC3411, but since you IMPORT from the MIB module in that doc, it should still be listed as noramative reference. - I believe that the WG mailing list has moved to IETF site, so pls update that information as well (in the MIB modules). - I wonder if alarmItuTc MODULE-IDENTITY would not be better (and more in line with the rest of the naming) ituAlarmTc MODULE-IDENTITY - In the ITU-ALARM-TC module, I see references in the TC DESCRIPTION clauses. Would it not be better to use a REFERENCE clause? - In the ITU-ALARM-MIB I see references in the various DESCRIPTION clauses. Would it not be better to use a REFERENCE clause? Thanks, Bert From mailnull@www1.ietf.org Sun Mar 16 21:19:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16017 for ; Sun, 16 Mar 2003 21:19:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H2ZPT11001 for disman-archive@odin.ietf.org; Sun, 16 Mar 2003 21:35:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H2ZPO10998 for ; Sun, 16 Mar 2003 21:35:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16009 for ; Sun, 16 Mar 2003 21:18:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H2YhO10952; Sun, 16 Mar 2003 21:34:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H2XNO10863 for ; Sun, 16 Mar 2003 21:33:23 -0500 Received: from falcon.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15975 for ; Sun, 16 Mar 2003 21:16:40 -0500 (EST) Received: from h-68-164-79-182.snvacaid.covad.net ([68.164.79.182] helo=oemcomputer) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ukDF-0004G4-00 for disman@ietf.org; Sun, 16 Mar 2003 18:18:53 -0800 Message-ID: <00ce01c2ec2b$e3f183c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Disman] Fw: Text Conferencing for the 56th IETF meeting in San Francisco Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 16 Mar 2003 18:21:16 -0800 Hi - Would anyone be interested in doing this for the disman WG session in San Francisco? Randy > From: "Marshall Rose" > To: > Sent: Tuesday, March 11, 2003 10:59 AM > Subject: Text Conferencing for the 56th IETF meeting in San Francisco > > Remote Access for the 56th IETF meeting in San Francisco: > Text Conferencing > > > At each IETF meeting, two of the working group meeting rooms are equipped > for video multicast and remote participation. That is, for every IETF > meeting slot, two of the working groups can see and hear the > meeting. For the 56th IETF, in *addition* to the usual network A/V, text > conferencing will be provided for every working group that meets. > > > All of the conference rooms will be hosted on > > > conference.ietf.jabber.com > > > and each is named using the official IETF abbreviation found in the > agenda (e.g., "apparea", "dhc", "forces", and so on -- for all the > examples that follow, we'll use "foobar" as the abbreviation). > > > Each conference room also has a 'bot which records everything that gets > sent. So, the minute taker can review this information right after the > meeting. > > > > 1. Before the meeting: > > > 1.1. If you want to participate > > > If you don't already have one, get yourself a Jabber client, here are some > suggestions: > > > platform suggestion > -------- ---------- > win32 http://exodus.jabberstudio.org > 'nix http://gabber.sf.net > macos http://jabberfox.sf.net > > > When you start the client for the first time, it will eventually ask if > you want to register on a public server. Go ahead and do > that. > > > If you want to find out more, instead of choosing these defaults, here > are pointers to some additional information: > > > list of clients: http://www.jabber.org/user/clientlist.php > howto: http://www.jabber.org/user/userguide/ > server list: http://www.jabber.org/user/publicservers.php > > > To make sure everything is running ok, do a "Join Group Chat" with your > Jabber client: > > > Group/Room: plenary > Server: conference.ietf.jabber.com > > > This conference room is up and running right now (although probably no > one will be in it when you connect). > > > 1.2. What the Chair does > > > If you want to make text conferencing available, you'll need to have a > volunteer scribe in the meeting room. The scribe will be typing in a > running commentary as to what's going on in the room (who's presenting, > what question is being asked, etc.) > > > So, why not send an email out on the mailing list now, before the > meeting, to ask for volunteers? > > > > 2. At the meeting > > > 2.1. What the Chair does > > > When a session starts, the chair asks if someone in the room is willing > to act as "scribe". If no one volunteers, read no further, we're done! > > > Otherwise, the scribe should do a "Join Group Chat" with their Jabber > client, e.g., > > > Group/Room: foobar > Server: conference.ietf.jabber.com > > > > 2.2. What the Scribe does > > > The scribe types in a running commentary as to what's going on in the > room. For example, if a speaker makes a presentation, the scribe types > in the URL for the presentation (more on this in a bit). > > > Simlarly, during question time, a remote participant can type a question > into the room and the scribe can pass it on to the speaker. > > > > 2.3. What each Presenter does > > > Each presenter should put a copy of their presentation on a web server > somewhere, so remote participants can follow along. > > > > 2.4. Where to find the conference log > > > http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/foobar/ > > > NOTE: the logging facility will not be active until later this week... > > > ####### > > From mailnull@www1.ietf.org Mon Mar 17 01:41:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22821 for ; Mon, 17 Mar 2003 01:41:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H6vr228497 for disman-archive@odin.ietf.org; Mon, 17 Mar 2003 01:57:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H6vrO28494 for ; Mon, 17 Mar 2003 01:57:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22816 for ; Mon, 17 Mar 2003 01:41:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H6vJO28475; Mon, 17 Mar 2003 01:57:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H6uQO28442 for ; Mon, 17 Mar 2003 01:56:26 -0500 Received: from falcon.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22773 for ; Mon, 17 Mar 2003 01:39:38 -0500 (EST) Received: from h-68-164-79-182.snvacaid.covad.net ([68.164.79.182] helo=oemcomputer) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18uoJi-0000av-00 for disman@ietf.org; Sun, 16 Mar 2003 22:41:50 -0800 Message-ID: <016101c2ec50$325d2860$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <7D5D48D2CAA3D84C813F5B154F43B15501271916@nl0006exch001u.nl.lucent.com> Subject: Re: [Disman] AD review of: draft-ietf-disman-alarm-mib-09.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 16 Mar 2003 22:41:10 -0800 Hi - WG chair hat on: Ok, we'll spin another draft to address these comments. Sharon and Dan: please review these before the WG session to identify any that might require discussion there. These all seem like reasonable comments, but I might be missing something. There were a couple of "wish list" items in the latest SG 4 liaison. I don't think this would be a good time to try to fold them into this revision, but I'm willing to listen to other opinions. Kam, An-ni, and Dave: please double-check the ARC draft I think several of these comments apply to that document as well. Both editing teams: when will the updates be ready? Randy > From: "Wijnen, Bert (Bert)" > To: "Disman (E-mail) (E-mail)" > Sent: Saturday, March 15, 2003 12:38 PM > Subject: [Disman] AD review of: draft-ietf-disman-alarm-mib-09.txt > > Sorry that it took so long. > > - New MIB boilerplate is now prefered > see www.ops.ietf.org > Nice thing is that it is much shorter and has far less > references. > - New MIB security guidelines to be followed > see www.ops.ietf.org > This one is a bit more elaborate than what you currently have > - We want MIB COPYright in the MODULE-IDENTITY in the DESCRIPTION > clause. See recent discussions on MIBS mailing list and in > draft-ietf-ops-mib-review-guidelines-01.txt > > - Page 4, you may want to add [RFC2119] refernece to the text > > - In the IANA maintained IANA-ITU-ALARM-TC mib, pls add in > DESCRIPTION clause the rules/guidelines for IANA on how to > add/change stuff in this MIB module. > Pls also add (or instruct RFC-editor to add) a (normative reference) > to the iana web site where this IANA maintained MIB module will be > placed. Also, add text to make it clear that this is only the > initial module and that the authoritative copy to be referenced > in any future document must be the one at iana web site. > Not sure if this was posted anywhere yet (it should show up in our > IESG minutes), but 20 Feb, IESG discussed this in their bi-weekly > telechat. Here is the result: > > The IESG discussed if new IANA-maintained MIB modules > should be published as (part of) an RFC. The consensus > is that the initial version indeed is to be in an RFC. > The version in that RFC MUST make sure that some > statement is made that the authoritative version of > the IANA-maintained MIB module is at the IANA web pages. > > I guess 2nd para in sect 5.2 does that. May want to add the ref to > the iana web page to be > > - ianaItuAlarmNumbers MODULE-IDENTITY > needs a REVISION clause > > - I prefer to see > ::= { mib-2 xx} -- to be assigned by IANA > That is, add the comment that IANA needs to assign a value > So that IANA can clearly see where they need to do things > This holds for all MIB modules. > In fact, I would change this: > DESCRIPTION > "Initial version, published as RFC XXXX." > > ::= { mib-2 xx } > Into > DESCRIPTION > "Initial version, published as RFC XXXX." > -- RFC-Editor assigns XXXX > ::= { mib-2 xx } -- to be assigned by IANA > > - When I see: ResourceId ::= TEXTUAL-CONVENTION > then I wonder... is this indeed a "resourceId" in the generic sense, > or have we limited it here for the ALARM-MIB type of resources? > In other words, would it maybe better to name it: > AlarmResourceId ::= TEXTUAL-CONVENTION > This to avoid conflict with other types of Resources? > > - I see: > alarmModelVarbindIndex OBJECT-TYPE > SYNTAX Integer32 > Does a negative value ever make sense? > Is an Unsigned32 SYNTAX better? > > - I cannot find a StorageType object or any text in a DESCRIPTION clause > that explains the persistency behavioru for alarmModelTable > I believe this is so for more tables in this(these) MIB module(s) > > - I see: > alarmActiveEngineID OBJECT-TYPE > SYNTAX SnmpEngineID > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The identification of the SNMP engine at which the alarm > originated. > If the alarm list can contain alarms from only one > engine or the alarm is from an SNMPv1 system, this object is > a zero length string." > But... the SnmpEngineID as specified in RFC3411 has a SIZE(5..32). > So it cannot be a zero length string. What you need is a > LocalSnmpEngineOrSnmpEngineID or some such. The PM-MIB in SNMPCONF > WG had same problem. In rev 13, they now have: > pmRoleContextEngineID OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (0 | 5..32)) > Maybe this calls for a common TC ?? If not, then you can solve it > in a similar way > > - I see: > alarmActiveContextName OBJECT-TYPE > SYNTAX SnmpAdminString > I wonder if it would not be (much) better to do: > alarmActiveContextName OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > After all, a contextName can only have that size as far as I know. > Or at least, we use that size in all the SNMP MIB mdoules we have > created sofar. > Occurs in alarmClearTable also > > - I see: > alarmClearMaximum OBJECT-TYPE > SYNTAX Integer32 > Would a negative value ever make sense? > > - I see Underscores in the IANA-ITU-ALARM-TC mib. Formally they are not allowed. > So why are we doing this? I do not see a good reason. Can we not just > leave the underscore out? > Maybe this was discussed on WG .. > pls refresh my memory if so. > > - SMIlint tells me about ITU-ALARM-MIB: > .\ITU-ALARM-MIB:359: warning: current group `ituAlarmServiceUserGroup' > is not referenced in this module > .\ITU-ALARM-MIB:369: warning: current group `ituAlarmSecurityGroup' > is not referenced in this module > .\ITU-ALARM-MIB:380: warning: current group `ituAlarmStatisticsGroup' > is not referenced in this module > Now... it is not mandatory to reference it. But see bottom of > page 23 of draft-ietf-ops-mib-review-guidelines-01.txt which > recommends to actually list them > - SMIlint tells me about ALARM-MIB: > .\ALARM-MIB:967: warning: current group `alarmActiveStatsGroup' > is not referenced in this module > .\ALARM-MIB:980: warning: current group `alarmClearGroup' is > not referenced in this module > .\ALARM-MIB:997: warning: current group `alarmNotificationsGroup' > is not referenced in this module > Same comments as above. > - I am missing an IPR statement. > - when you do an update, pls update the year for the copyrigth statements > in various places. > - same for dates in MIB modules. > - Pls realize that RFCs that contain MIB modules from which you IMPORT > anything must be referenced in a normative way. I say this, cause > for example the new boilerplate no longer refrences RFC3411, but since > you IMPORT from the MIB module in that doc, it should still be listed > as noramative reference. > - I believe that the WG mailing list has moved to IETF site, so pls > update that information as well (in the MIB modules). > > - I wonder if alarmItuTc MODULE-IDENTITY > would not be better (and more in line with the rest of the naming) > ituAlarmTc MODULE-IDENTITY > - In the ITU-ALARM-TC module, I see references in the TC DESCRIPTION > clauses. Would it not be better to use a REFERENCE clause? > - In the ITU-ALARM-MIB I see references in the various DESCRIPTION > clauses. Would it not be better to use a REFERENCE clause? > > Thanks, > Bert From mailnull@www1.ietf.org Mon Mar 17 01:59:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23170 for ; Mon, 17 Mar 2003 01:59:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H7FRD07479 for disman-archive@odin.ietf.org; Mon, 17 Mar 2003 02:15:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H7FQO07475 for ; Mon, 17 Mar 2003 02:15:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23160 for ; Mon, 17 Mar 2003 01:58:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H7F4O07454; Mon, 17 Mar 2003 02:15:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H7EeO07420 for ; Mon, 17 Mar 2003 02:14:40 -0500 Received: from falcon.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23139 for ; Mon, 17 Mar 2003 01:57:52 -0500 (EST) Received: from h-68-164-79-182.snvacaid.covad.net ([68.164.79.182] helo=oemcomputer) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18uobN-0000pW-00; Sun, 16 Mar 2003 23:00:05 -0800 Message-ID: <016a01c2ec52$b54708c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] question regarding the alarm mib X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 16 Mar 2003 22:59:08 -0800 Hi - I haven't seen a response to this query, so I've taken a stab at it, in-line below. Perhaps it would make sense address it explicitly in the update to the I-D, which we need to do anyway to address IESG concerns. Comments? Randy > From: "Donald, Keith" > To: "Disman (E-mail)" > Sent: Wednesday, February 19, 2003 11:06 AM > Subject: [Disman] question regarding the alarm mib > > I have a question regarding a semantic of the alarm mib that I can't find > directly discussed in the RFC: > > What is the expected behaivior when an active alarm transitions to another > active state? (as opposed to a clear state.) I see a couple of different > possibilities and was wondering which one is the right one: > > 1. The previously active state is moved to the "cleared" alarm table to > note it as a "historical" alarm. The new active state is added to the > activeAlarm table. > - The problem with this approach is it looks like their are two > different alarms (and one has cleared), when in reality there is only one alarm > that has transitioned from one active state to another over the course of its > life. I think this is *not* intended. The description of alarmClearTable and its columns makes it (relatively) clear that only a cleared alarm (alarmModelState value 1) would go there. > 2. The new active alarm state simply "replaces" the previously active > alarm state in the alarmActive table. > - The problem here is you lose information about the previous > alarm state. This option seems unacceptable. I believe this is the intent. I don't see why it would be unacceptable. If one cared about previous alarms, a log (as in RFC 3014) would seem to be a more appropriate mechanism. > 3. The new active alarm state replaces the previous state, and the > previous state is added as a "historical" state for that active alarm instance. > - This seems like the best solution, but is this supported by > the current model? No. > Here is an example of what I mean: > > Suppose a simple "Temperature" alarm model exists and has states of: > Temperature Normal (clear) > Temperature Minor > Temperature Major > Temperature Critical > > When a "Temperature Minor" alarm condition is detected, the alarm is added to > the activeAlarm table and any triggering event information is associated with > it. What happens when if the alarm transitions from Minor to Major, or from > Minor to Critical? Should one activeAlarm instance track these state > transitions explicitly over the course of its life? Or is each state transition > viewed as a separate alarm? Let's be careful with the terminology. There would be a single "active alarm" which would reflect the severity levels associated with the various alarms (in the X.733 sense) processed. > Thank you for your help, > > Keith Donald > kdonald@harris.com > From mailnull@www1.ietf.org Tue Mar 18 11:32:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16675 for ; Tue, 18 Mar 2003 11:32:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IGnkM26825 for disman-archive@odin.ietf.org; Tue, 18 Mar 2003 11:49:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IGnjO26822 for ; Tue, 18 Mar 2003 11:49:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16653 for ; Tue, 18 Mar 2003 11:32:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IGmiO26727; Tue, 18 Mar 2003 11:48:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IGlSO26640 for ; Tue, 18 Mar 2003 11:47:28 -0500 Received: from mid-2.inet.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16542 for ; Tue, 18 Mar 2003 11:29:55 -0500 (EST) Received: from [::ffff:213.92.1.193] by mid-2.inet.it via I-SMTP-4.3.7-430 id ::ffff:213.92.1.193+oa7uWr7mISRT; Tue, 18 Mar 2003 17:32:09 +0100 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Harrie Hazewinkel To: disman@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <8E96793C-595F-11D7-B329-0003934A5A7E@jumpy.it> X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Subject: [Disman] comments for draft-ietf-disman-alarm-mib-09.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Mar 2003 17:34:57 +0100 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I noticed there would be a new revision of the ALARM-MIB, maybe some of these comments could be addressed also. See below. > 3. Alarm Management Framework > > 3.1 Terminology > > Error > A deviation of a system from normal operation. > > Fault > Lasting error or warning condition. Since 'error' is defined as a term, I believe it may be wise to define the 'warning' as well. Since I cannot find a real definition of 'alarm model' and 'alarm list', but only usages I would suggest these terms to be defined here as well. > 3.2 Alarm Management Architecture FORMAT NIT: Put this section header on the same page as the beginning of the section. What I miss is a small description of the components and there interactions of the figure. > 3.3.1 Modular Alarm Architecture > > The subject of alarm management can potentially cover a large number > of topics including real-time alarms, historical alarms, alarm > correlation, and alarm suppression, to name a few. Within each of > these topics, there are a number of established models that could be > supported. This memo focuses on a subset of this problem space, but > describes a modular SNMP alarm management framework. What is this subset?? > 3.3.3 Problem Indication > > The Alarm MIB provides a means to tell what Notifications are just > informational events or not of interest to the manager for other > reasons by not including them in any alarm models. How does this work for multiple managers?? For some it may be an alarm needing a notification and others not. Is that where you need the SNMP-NOTIFICATION-MIB and SNMP-TARGET-MIB?? > 3.3.5 Identifying Resource under Alarm > > This MIB provides a generic method for identifying the resource by Which MIB?? There are 2 in this document. The use of 'This MIB' happens also later in the document. It may be mis-leading and, therefore, can better be specified which MIB is ment. > 3.3.6 Means of obtaining ITU alarm information > > Alarm Information, as defined in ITU alarm models [M.3100], is > optionally available to implementations through the optional support > of the ITU-ALARM-MIB. Just for reference, where can I find this document?? As if this is a feature of the architecture of the previous picture I do not see anything related to ITU. > 3.3.10 Historical Alarm Management > > Some systems may have a requirement that information on alarms that > are no longer active is available. This memo provides a clear table 'a clear table' -> 'a table'. What is ment with 'a clear table' anyway?? > to support this requirement. > > This can also be achieved through the support of the Notification > log MIB [RFC3014] to store alarm state transitions. Why would one to create in this document an alternative for 'Historical Alarm Management'?? > > 3.4 Security > > > For the purpose of this discussion, "security credentials" means the 'For the purpose of this discussion' -> 'This document' > The Alarm MIB has the notion of a named alarm list. By using alarm > list names and view-based access control [RFC2575] a network > administrator can provide different access for different users. When > an application creates an alarm model (indexed in part by the alarm > list name) the security credentials of the creator remain associated 'creator' of what?? The application or managed objects?? Explanation, if I implement an application I could be seen as the creator, but the use here is defnitely different. > The managed system SHOULD NOT apply access control when processing > remotely-generated Notifications using the alarm models. In those > cases the security of the information in the alarm tables SHOULD be > left to the normal, overall access control for those tables. What is 'normal'?? Please, specify. > 3.6 Notification Varbind Storage and Reference > > In SNMPv1, the varbinds in the Trap-PDU sent over the wire map one > to one into those varbinds listed in the SMI of the trap in the MIB > in which it was defined. In the case of linkDown trap, the first > varbind can unambiguously be identified as ifIndex. With the > introduction of the InformRequest-PDU and SNMPv2-Trap-PDU types, > which send sysUptime and snmpTrapOID as the first two varbinds, > while the SMI in the MIB where the Notification is defined only > lists additional varbinds, the meaning of "first varbind" becomes > less clear. In the case of the linkDown Notification, referring to > the first varbind could potentially be interpreted as either the > sysUptime or ifIndex. I understand the above described problem, but I am not sure what it adds. The usage of 'first' in this section is left a bit in the open. I would suggest to drop this paragraph, the next paragraph defines this and better I would say. > The varbind storage approach taken in the Alarm MIB is that 'approach taken -> 'defined' > sysUptime and snmpTrapOID shall always be stored in the active alarm 'shall always' -> 'SHALL' > variable table as entry 1 and 2 respectively, regardless of whether > the transport was the Trap-PDU, the InformRequest-PDU or the > SNMPv2-Trap-PDU. If the incoming Notification is an SNMPv1 Trap-PDU > then an appropriate value for sysUpTime.0 or snmpTrapOID.0 shall be > determined by using the rules in section 3.1 of [RFC2576]. > > The varbind reference approach taken in the Alarm MIB is that, for > variables such as the alarmModelVarbindIndex, the first two > obligatory varbinds of the InformRequest-PDU and SNMPv2-Trap-PDU are > ignored, and the index aligns with the Trap-PDU and the SMI. In the > case of linkDown, the first varbind would always be ifIndex. I would for simplicitly reasons make both approaches equal. I understnad this is a real semantic change, but if the WG prefers this it is fine by me. > 3.7 Relation to Notification Log MIB > > The Alarm MIB is intended to complement the Notification Log > MIB[RFC3014], but can be used independently. The alarmActiveTable > is defined in manner similar to that of the nlmLogTable. This > format allows for the storage of any Trap or Notification that can > be defined using SMIv1 or SMIv2. Using the same format as the > Notification log MIB also simplifies operations for systems choosing > to implement both MIBs. If they use the same format, it could be a possibility to use the nlmLogTable. I understand it is not possible, but an explaination why will help an implementor, I guess. > The object alarmActiveLogPointer points, for each entry in the > alarmActiveLogTable, to the log index in the Notification log MIB, > if used. I believe this can create confusion, since a RowPointer must point to an accessible object in a table. In many cases the 'index' of a table is 'not-accessible'. > 3.8 Relationship with the Event MIB > > During the work and discussions in the Working Group, the issue of > the relationship between the MIB modules and the Event MIB [RFC2981] > was raised. I would say, only the outcome of the discussion is usefull. I suggest, to drop the above sentence. > 4.1 Overview > > The alarmModelTable contains information that is applicable to all > instances of an alarm. It can be populated at start-up with all > alarms that could happen on a system or later configured by a > management application. I believe the above section part is confusing in the sense that it uses the name alarmModelTable if it only provides a list of alarms. Would therefore a table named alarmListTable not be better representing its semantics?? > 4.1.1 Extensibility > > The relationship between the Alarm MIB and the other alarm model MIB > modules is expressed by the following: The alarmModelTable has a > corresponding table in the specific MIB. For each row in the > specific MIB alarm model table there is one row in the > alarmModelTable. The alarmActiveTable has a corresponding table in > the specific MIBs. For each row in the specific MIB active alarm > table, there is one row in the alarmActiveTable. The > alarmModelSpecificPointer object in the alarmModelTable points to > the specific model entry in an extended alarm model table > corresponding to this particular alarm. The > alarmActiveSpecificPointer object in the alarmActiveTable points to > the specific active alarm entry in an extended active alarm table > corresponding to this particular alarm instance. Not sure if this section would be enough to make additional alarm modules. Would it not be better add more guidelines on how to make a new model?? I also believe the making a specific alarm model involves duplicating part of the generic alarm-mib. Is that what is needed? > 4.1.3 Alarm State Transition Notification > > Alarms are modelled by defining all possible states in the > alarmModelTable, as well as defining alarmModelNotificationId, > alarmModelVarbindIndex, and alarmModelVarbindValue for each of the > possible alarm states. Optionally, ituAlarmPerceivedSeverity models > the states in terms of ITU perceived severity. Here I start getting confused of what the alarmModelTable is about. Before it said it contains all alarms available in a system, now it defines all possible states of an alarm. OK, I admit I did not read the MIB definition itself yet (at this point). > > 4.1.4 Active Alarm Resource Identifier > > If alarmModelResourcePrefix has a value of 0.0, then > alarmActiveResourceId is simply the variable identifier of the first > Notification varbind that matches the prefix defined in > alarmModelVarbindSubtree. Otherwise, alarmActiveResourceId is > calculated by appending the instance information from the first > Notification varbind that matches alarmModelVarbindSubtree to the > prefix defined in alarmModelResourcePrefix. The instance information > is the portion of the variable identifier following the part that > matched alarmModelVarbindSubtree. If no match is found, then > alarmModelResourceId is simply the value of > alarmModelResourcePrefix. 'alarmModelResourceId' -> 'alarmActiveResourceId'. > > In addition to this, the variable bindings from the Notifications > that signal the alarm state transitions are stored in the active > alarm table. 'active alarm table' -> 'active alarm variable table' Not sure if that is ment here. > To set the resource Id to be the ifIndex, configure as follows: > alarmModelVarbindSubtree = ifIndex (1.3.6.1.2.1.2.2.1.1) > alarmModelResourcePrefix = 0.0 > > Alternatively, since ifIndex is the first varbind, the following > would also work, but might be less meaningful to a human reader Why 'human reader' does it not count for an automatic as well? > > B) Consider an alarm modelled using the bgpBackwardTransition 'B)' -> 'C)' > > 4.2 Definitions > > ALARM-MIB DEFINITIONS ::= BEGIN > > > alarmMIB MODULE-IDENTITY > LAST-UPDATED "200208280000Z" > ORGANIZATION "IETF Distributed Management Working Group" > CONTACT-INFO > "WG EMail: disman@dorothy.bmc.com > Subscribe: disman-request@dorothy.bmc.com A reference to the WG web-page?? As recommended in the mib-reviewers id draft-ietf-ops-mib-review-guidelines-01.txt (also valid for the other MODULE-IDENTITY-s) > -- Textual Conventions > > ResourceId ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "A unique identifier for this resource. > > The type of the resource can be determined by looking > at the OID that describes the resource. > > Resources must be identified in a consistent manner. > For example, if this resource is an interface, this > object MUST point to an ifIndex." How are multiple indexes handled?? It looks like that a resource is that part of a system that has just a single index. Some clarification would help I believe. > alarmModelVarbindSubtree OBJECT-TYPE > alarmModelResourcePrefix OBJECT-TYPE > Since both descriptions speak of 'indexes' are scalars excluded? > alarmListName OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE(0..32)) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The name of the list of alarms. This SHOULD be the same as > nlmLogName if the Notification Log MIB [RFC3014] is supported. > > An implementation may allow multiple named alarm lists, up to > some implementation-specific limit (which may be none). A > zero-length list name is reserved for creation and deletion > by the managed system, and MUST be used as the default log > name by systems that do not support named alarm lists." > ::= { alarmActiveEntry 1 } I am not seeing why this object needs to be defined. One could use the nlmLogName directly in the indexes where alarmListName is used. The nlmLogName is not-accessible and therefore it is not needed to implement the NOTIFICATION-LOG-MIB module. And as it looks the association is needed if the NOTIFICATION-LOG-MIB exist. Neither, I do not fully understand why it is defined in this table and not in the alarmModelTable. A definition of the alarmListName in that table looks more logic to me, but I am maybe missing something. If the WG wants to keep this object, I do not object. > > alarmActiveDateAndTime OBJECT-TYPE > DESCRIPTION > "The local date and time when the error occurred. I would drop 'local', as long as it is known in which timezone the alarm went active it is no problem. For instance, you can have systems in all timezones, but still using UTC as its timezone. Then 'local' is not really 'local'. (Also in some others) > alarmActiveVariables OBJECT-TYPE > DESCRIPTION > "The number of variables in alarmActiveVariableTable for this > alarm. Also, the number of varbinds for the notification > associated with this alarm state." I beleive that the part 'Also,...' makes it more unclear on the value, since there is a difference in varbinds between V2 or V1 trap/notification PDU. I suggest dropping that. The table refered to, 'alarmActiveVariableTable', provides enough information. > alarmActiveNotificationID OBJECT-TYPE Is this not retrievable from the alarmModelTable by using the alarmActiveModelPointer?? > alarmActiveLogPointer OBJECT-TYPE > DESCRIPTION > "A pointer to the corresponding row in a > notification logging MIB where the state change > notification for this active alarm is logged. > If no log entry applies to this active alarm, > then this object MUST have the value of 0.0" For clarity, I suggest using here a specific reference towards the table in which the log index resides within the MIB. > alarmActiveVariableValueType OBJECT-TYPE > SYNTAX INTEGER { > counter32(1), > unsigned32(2), > timeTicks(3), > integer32(4), > ipAddress(5), > octetString(6), > objectId(7), > counter64(8), > opaque(9) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The type of the value. One and only one of the value > objects that follow is used, based on this type." Also 'the value' is better described by 'the value of the object indicated by alarmActiveVariableID'. The last part I am not sure what an implementor should do. Should it provide dummy values for the 'not used' variables or create 'holes' in the table. > alarmActiveVariableCounter32Val OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value when alarmActiveVariableType is 'counter32'." > ::= { alarmActiveVariableEntry 4 } About the 'alarmActiveVariable.....Val' objects it should be noted that the value has no significance if 'alarmActiveVariableType' is indicating to that type/object. Also 'The value' is better described by 'The value of the object indicated by alarmActiveVariableID' > > alarmActiveVariableIpAddressVal OBJECT-TYPE > SYNTAX IpAddress > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value when alarmActiveVariableType is 'ipAddress'." > ::= { alarmActiveVariableEntry 9 } Not sure what to do here. It is not recommended to use IpAddress as a type, but replacing it by InetAddress is neither possible, that would result in a alarmActiveVariableOctetStringVal. Now the question, how can a management station detect which InetAddress type is used?? > -- Statistics -- > > alarmActiveStatsActives OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The total number of active alarms since system restarted." How is the persistence defined when only the SNMP engine reboots?? > alarmClearIndex OBJECT-TYPE > SYNTAX Unsigned32 (1..4294967295) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A strictly monotonically increasing integer which acts > as the index of entries within the named alarm list. > It wraps back to 1 after it reaches its maximum value. > > This object has the same value as the alarmActiveIndex that > this alarm instance had when it was active." > ::= { alarmClearEntry 1 } The value will always have the same value as the alarmActiveIndex, but I believe that alarms will not always be cleared in the same order as they are active. Thus the requirement of a 'strictly monotonically increasing integer' is not usefull here (maybe even not possible). > > alarmClearLogIndex OBJECT-TYPE > SYNTAX Unsigned32 (0..4294967295) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This number MUST be the same as the log index of the > applicable row in the notification log MIB, if it exists. > If no log index applies to the trap, then this object > MUST have the value of 0." For clarity, I suggest using here a specific reference towards the table in which the log index resides. > alarmClearState NOTIFICATION-TYPE > DESCRIPTION > "An instance of the alarm indicated by > alarmActiveModelPointer has been cleared against > the entity indicated by alarmACtiveResourceId." ^ 'alarmACtiveResourceId' -> 'alarmActiveResourceId' > alarmCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The compliance statement for systems supporting > the Alarm MIB." > MODULE -- this module > MANDATORY-GROUPS { > alarmActiveGroup, > alarmModelGroup > } > ::= { alarmCompliances 1 } Since there are read-create objects, the mib-review document indicates there should be a FullCompliance and ReadOnlyCompliance statement. > 5.1 Overview > > This MIB module defines alarm information specific to the alarm > model defined in ITU M.3100 [M.3100], X.733[X.733] and X.736[X.736]. A short description of the ITU Alarm Model would not hurt a reader its understanding. Perticular, those that cannot access the ITU standards themselves, like me. > ianaItuAlarmNumbers MODULE-IDENTITY > LAST-UPDATED "200208280000Z" > ORGANIZATION "IANA" > CONTACT-INFO > "Postal: Internet Assigned Numbers Authority > Internet Corporation for Assigned Names > > and Numbers nit: little formatting. :-)) > ituAlarmActiveServiceUser OBJECT-TYPE > DESCRIPTION > "Represents the SericeUser object from [X.736]." ^ 'SericeUser' -> 'ServiceUser' Maybe the description of the MODULE-IDENTITY should also state that only values may be added when they are defined by the ITU alarm model. > > ituAlarmActiveStatsIndeterminateCurrent OBJECT-TYPE > SYNTAX Gauge32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "A count of the current number of active alarms with a > ituAlarmPerceivedSeverity of indeterminate." > ::= { ituAlarmActiveStatsEntry 1 } Is it the idea to add an extra column for every later added perceived severity?? Otherwise, the perceived severity could be an index and the table has just 2 columns current and total. > ituAlarmCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The compliance statement for systems supporting > the ITU Alarm MIB." > MODULE -- this module > MANDATORY-GROUPS { > ituAlarmGroup > } > ::= { ituAlarmCompliances 1 } Since there are read-write objects, the mib-review document indicates there should be a FullCompliance and ReadOnlyCompliance statement. > 6.4 Printer MIB Alarm Example > > Consider the following Notifications defined in the > printer MIB [RFC1759]: I understand the problem with copying from another document for complete definitions, but here are some copied and not all objects as defined in the OBJECTS-clause of 'printerV2Alert'. I would suggest add all, or as it seems the most used 'prtAlertGroup' or none. > > prtAlertSeverityLevel OBJECT-TYPE > -- This value is a type 1 enumeration > SYNTAX INTEGER { > other(1), > critical(3), > warning(4) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The level of severity of this alert table entry. The printer > determines the severity level assigned to each entry into the > table." > ::= { prtAlertEntry 2 } > > printerV2Alert NOTIFICATION-TYPE > OBJECTS { prtAlertIndex, prtAlertSeverityLevel, prtAlertGroup, > prtAlertGroupIndex, prtAlertLocation, prtAlertCode } > STATUS current > DESCRIPTION > "This trap is sent whenever a critical event is added to the > prtAlertTable." > ::= { printerV2AlertPrefix 1 } > 6.5 RMON Alarm Example > > alarmModelIndex 6 > alarmModelState 2 > alarmModelNotificationId RisingAlarm > alarmModelVarbindIndex 0 > alarmModelVarbindValue 0 > alarmModelDescription "RMON Rising Alarm" > alarmModelSpecificPointer 0.0 > alarmModelRowStatus active (1) > alarmModelVarbindSubtree alarmIndex > alarmModelResourcePrefix 0.0 > alarmModelRowStatus active (1) Has twice 'alarmModelRowStatus' (first need to be deleted). regards, Harrie From mailnull@www1.ietf.org Wed Mar 19 01:17:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17903 for ; Wed, 19 Mar 2003 01:17:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J6YmG24726 for disman-archive@odin.ietf.org; Wed, 19 Mar 2003 01:34:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J6YmO24723 for ; Wed, 19 Mar 2003 01:34:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17897 for ; Wed, 19 Mar 2003 01:17:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J6YPO24701; Wed, 19 Mar 2003 01:34:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IEvBO18328 for ; Tue, 18 Mar 2003 09:57:11 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11619 for ; Tue, 18 Mar 2003 09:39:45 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2IEfuwv009882; Tue, 18 Mar 2003 15:41:56 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 18 Mar 2003 15:40:40 +0100 Message-ID: <034BEFD03799D411A59F00508BDF754606C5F452@esealnt448.al.sw.ericsson.se> From: "Jan Engfeldt (EAB)" To: "'rfc-editor@rfc-editor.org'" , "'disman@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Disman] Patents on MIBs? Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Mar 2003 15:35:42 +0100 Hello, I been told that the DISMAN MIB is patented by Nortel, is this correct? regards Jan Engfeldt SPM Management Solutions Phone:+46850876315 Mobile: +46702674650 Fax: +46859436030 From mailnull@www1.ietf.org Wed Mar 19 01:49:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18411 for ; Wed, 19 Mar 2003 01:49:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J76eT29677 for disman-archive@odin.ietf.org; Wed, 19 Mar 2003 02:06:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J76dO29674 for ; Wed, 19 Mar 2003 02:06:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18407 for ; Wed, 19 Mar 2003 01:48:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J765O29036; Wed, 19 Mar 2003 02:06:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J75JO28474 for ; Wed, 19 Mar 2003 02:05:19 -0500 Received: from conure.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18394 for ; Wed, 19 Mar 2003 01:47:30 -0500 (EST) Received: from h-68-164-17-66.snvacaid.covad.net ([68.164.17.66] helo=oemcomputer) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18vXOR-00028v-00; Tue, 18 Mar 2003 22:49:43 -0800 Message-ID: <016001c2ede4$3af8b760$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <8E96793C-595F-11D7-B329-0003934A5A7E@jumpy.it> Subject: Re: [Disman] comments for draft-ietf-disman-alarm-mib-09.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Mar 2003 22:53:21 -0800 Hi Harrie - Thanks, the quick and detailed comments are greatly appreciated. I'd like to ask the document editors to make a quick pass through these to identify the ones they consider purely editorial, so that we can spend some time on the technical ones at the WG session Wednesday afternoon. Ok, Sharon? (Since I know Dan may not be able to attend the whole session.) Randy > From: "Harrie Hazewinkel" > To: > Sent: Tuesday, March 18, 2003 8:34 AM > Subject: [Disman] comments for draft-ietf-disman-alarm-mib-09.txt > > Hi, > > I noticed there would be a new revision of the ALARM-MIB, > maybe some of these comments could be addressed also. > See below. > > > 3. Alarm Management Framework > > > > 3.1 Terminology > > > > Error > > A deviation of a system from normal operation. > > > > Fault > > Lasting error or warning condition. > > Since 'error' is defined as a term, I believe it may be wise to > define the 'warning' as well. > > Since I cannot find a real definition of 'alarm model' and > 'alarm list', but only usages I would suggest these terms > to be defined here as well. > > > > 3.2 Alarm Management Architecture > > FORMAT NIT: Put this section header on the same page as the beginning > of the section. > > What I miss is a small description of the components and there > interactions > of the figure. > > > 3.3.1 Modular Alarm Architecture > > > > The subject of alarm management can potentially cover a large number > > of topics including real-time alarms, historical alarms, alarm > > correlation, and alarm suppression, to name a few. Within each of > > these topics, there are a number of established models that could be > > supported. This memo focuses on a subset of this problem space, but > > describes a modular SNMP alarm management framework. > > What is this subset?? > > > 3.3.3 Problem Indication > > > > The Alarm MIB provides a means to tell what Notifications are just > > informational events or not of interest to the manager for other > > reasons by not including them in any alarm models. > > How does this work for multiple managers?? For some it may be an alarm > needing > a notification and others not. Is that where you need the > SNMP-NOTIFICATION-MIB > and SNMP-TARGET-MIB?? > > > 3.3.5 Identifying Resource under Alarm > > > > This MIB provides a generic method for identifying the resource by > > Which MIB?? There are 2 in this document. The use of 'This MIB' happens > also later in the document. It may be mis-leading and, therefore, > can better be specified which MIB is ment. > > > 3.3.6 Means of obtaining ITU alarm information > > > > Alarm Information, as defined in ITU alarm models [M.3100], is > > optionally available to implementations through the optional support > > of the ITU-ALARM-MIB. > > Just for reference, where can I find this document?? As if this is a > feature > of the architecture of the previous picture I do not see anything > related to ITU. > > > 3.3.10 Historical Alarm Management > > > > Some systems may have a requirement that information on alarms that > > are no longer active is available. This memo provides a clear table > > 'a clear table' -> 'a table'. What is ment with 'a clear table' anyway?? > > > to support this requirement. > > > > This can also be achieved through the support of the Notification > > log MIB [RFC3014] to store alarm state transitions. > > Why would one to create in this document an alternative for > 'Historical Alarm Management'?? > > > > > 3.4 Security > > > > > > For the purpose of this discussion, "security credentials" means the > > 'For the purpose of this discussion' -> 'This document' > > > The Alarm MIB has the notion of a named alarm list. By using alarm > > list names and view-based access control [RFC2575] a network > > administrator can provide different access for different users. When > > an application creates an alarm model (indexed in part by the alarm > > list name) the security credentials of the creator remain associated > > 'creator' of what?? The application or managed objects?? > Explanation, if I implement an application I could be seen as the > creator, > but the use here is defnitely different. > > > The managed system SHOULD NOT apply access control when processing > > remotely-generated Notifications using the alarm models. In those > > cases the security of the information in the alarm tables SHOULD be > > left to the normal, overall access control for those tables. > > What is 'normal'?? Please, specify. > > > 3.6 Notification Varbind Storage and Reference > > > > In SNMPv1, the varbinds in the Trap-PDU sent over the wire map one > > to one into those varbinds listed in the SMI of the trap in the MIB > > in which it was defined. In the case of linkDown trap, the first > > varbind can unambiguously be identified as ifIndex. With the > > introduction of the InformRequest-PDU and SNMPv2-Trap-PDU types, > > which send sysUptime and snmpTrapOID as the first two varbinds, > > while the SMI in the MIB where the Notification is defined only > > lists additional varbinds, the meaning of "first varbind" becomes > > less clear. In the case of the linkDown Notification, referring to > > the first varbind could potentially be interpreted as either the > > sysUptime or ifIndex. > > I understand the above described problem, but I am not sure what > it adds. The usage of 'first' in this section is left a bit in the > open. > I would suggest to drop this paragraph, the next paragraph defines this > and better I would say. > > > The varbind storage approach taken in the Alarm MIB is that > > 'approach taken -> 'defined' > > > sysUptime and snmpTrapOID shall always be stored in the active alarm > > 'shall always' -> 'SHALL' > > > variable table as entry 1 and 2 respectively, regardless of whether > > the transport was the Trap-PDU, the InformRequest-PDU or the > > SNMPv2-Trap-PDU. If the incoming Notification is an SNMPv1 Trap-PDU > > then an appropriate value for sysUpTime.0 or snmpTrapOID.0 shall be > > determined by using the rules in section 3.1 of [RFC2576]. > > > > The varbind reference approach taken in the Alarm MIB is that, for > > variables such as the alarmModelVarbindIndex, the first two > > obligatory varbinds of the InformRequest-PDU and SNMPv2-Trap-PDU are > > ignored, and the index aligns with the Trap-PDU and the SMI. In the > > case of linkDown, the first varbind would always be ifIndex. > > I would for simplicitly reasons make both approaches equal. > I understnad this is a real semantic change, but if the WG > prefers this it is fine by me. > > > 3.7 Relation to Notification Log MIB > > > > The Alarm MIB is intended to complement the Notification Log > > MIB[RFC3014], but can be used independently. The alarmActiveTable > > is defined in manner similar to that of the nlmLogTable. This > > format allows for the storage of any Trap or Notification that can > > be defined using SMIv1 or SMIv2. Using the same format as the > > Notification log MIB also simplifies operations for systems choosing > > to implement both MIBs. > > If they use the same format, it could be a possibility to use > the nlmLogTable. I understand it is not possible, but an explaination > why will help an implementor, I guess. > > > The object alarmActiveLogPointer points, for each entry in the > > alarmActiveLogTable, to the log index in the Notification log MIB, > > if used. > > I believe this can create confusion, since a RowPointer must > point to an accessible object in a table. In many cases the 'index' > of a table is 'not-accessible'. > > > 3.8 Relationship with the Event MIB > > > > During the work and discussions in the Working Group, the issue of > > the relationship between the MIB modules and the Event MIB [RFC2981] > > was raised. > > I would say, only the outcome of the discussion is usefull. I suggest, > to > drop the above sentence. > > > 4.1 Overview > > > > The alarmModelTable contains information that is applicable to all > > instances of an alarm. It can be populated at start-up with all > > alarms that could happen on a system or later configured by a > > management application. > > I believe the above section part is confusing in the sense that > it uses the name alarmModelTable if it only provides a list of alarms. > Would therefore a table named alarmListTable not be better > representing its semantics?? > > > 4.1.1 Extensibility > > > > The relationship between the Alarm MIB and the other alarm model MIB > > modules is expressed by the following: The alarmModelTable has a > > corresponding table in the specific MIB. For each row in the > > specific MIB alarm model table there is one row in the > > alarmModelTable. The alarmActiveTable has a corresponding table in > > the specific MIBs. For each row in the specific MIB active alarm > > table, there is one row in the alarmActiveTable. The > > alarmModelSpecificPointer object in the alarmModelTable points to > > the specific model entry in an extended alarm model table > > corresponding to this particular alarm. The > > alarmActiveSpecificPointer object in the alarmActiveTable points to > > the specific active alarm entry in an extended active alarm table > > corresponding to this particular alarm instance. > > Not sure if this section would be enough to make additional alarm > modules. > Would it not be better add more guidelines on how to make a new model?? > I also believe the making a specific alarm model involves duplicating > part of the generic alarm-mib. Is that what is needed? > > > > 4.1.3 Alarm State Transition Notification > > > > Alarms are modelled by defining all possible states in the > > alarmModelTable, as well as defining alarmModelNotificationId, > > alarmModelVarbindIndex, and alarmModelVarbindValue for each of the > > possible alarm states. Optionally, ituAlarmPerceivedSeverity models > > the states in terms of ITU perceived severity. > > Here I start getting confused of what the alarmModelTable is about. > Before it said it contains all alarms available in a system, now > it defines all possible states of an alarm. > OK, I admit I did not read the MIB definition itself yet (at this > point). > > > > > 4.1.4 Active Alarm Resource Identifier > > > > If alarmModelResourcePrefix has a value of 0.0, then > > alarmActiveResourceId is simply the variable identifier of the first > > Notification varbind that matches the prefix defined in > > alarmModelVarbindSubtree. Otherwise, alarmActiveResourceId is > > calculated by appending the instance information from the first > > Notification varbind that matches alarmModelVarbindSubtree to the > > prefix defined in alarmModelResourcePrefix. The instance information > > is the portion of the variable identifier following the part that > > matched alarmModelVarbindSubtree. If no match is found, then > > alarmModelResourceId is simply the value of > > alarmModelResourcePrefix. > > 'alarmModelResourceId' -> 'alarmActiveResourceId'. > > > > > In addition to this, the variable bindings from the Notifications > > that signal the alarm state transitions are stored in the active > > alarm table. > > 'active alarm table' -> 'active alarm variable table' > Not sure if that is ment here. > > > To set the resource Id to be the ifIndex, configure as follows: > > alarmModelVarbindSubtree = ifIndex (1.3.6.1.2.1.2.2.1.1) > > alarmModelResourcePrefix = 0.0 > > > > Alternatively, since ifIndex is the first varbind, the following > > would also work, but might be less meaningful to a human reader > > Why 'human reader' does it not count for an automatic as well? > > > > > B) Consider an alarm modelled using the bgpBackwardTransition > > 'B)' -> 'C)' > > > > > 4.2 Definitions > > > > ALARM-MIB DEFINITIONS ::= BEGIN > > > > > > alarmMIB MODULE-IDENTITY > > LAST-UPDATED "200208280000Z" > > ORGANIZATION "IETF Distributed Management Working Group" > > CONTACT-INFO > > "WG EMail: disman@dorothy.bmc.com > > Subscribe: disman-request@dorothy.bmc.com > > A reference to the WG web-page?? As recommended in the > mib-reviewers id draft-ietf-ops-mib-review-guidelines-01.txt > (also valid for the other MODULE-IDENTITY-s) > > > -- Textual Conventions > > > > ResourceId ::= TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "A unique identifier for this resource. > > > > The type of the resource can be determined by looking > > at the OID that describes the resource. > > > > Resources must be identified in a consistent manner. > > For example, if this resource is an interface, this > > object MUST point to an ifIndex." > > How are multiple indexes handled?? It looks like that a resource is > that part of a system that has just a single index. > Some clarification would help I believe. > > > alarmModelVarbindSubtree OBJECT-TYPE > > alarmModelResourcePrefix OBJECT-TYPE > > > Since both descriptions speak of 'indexes' are scalars excluded? > > > > alarmListName OBJECT-TYPE > > SYNTAX SnmpAdminString (SIZE(0..32)) > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The name of the list of alarms. This SHOULD be the same as > > nlmLogName if the Notification Log MIB [RFC3014] is supported. > > > > An implementation may allow multiple named alarm lists, up to > > some implementation-specific limit (which may be none). A > > zero-length list name is reserved for creation and deletion > > by the managed system, and MUST be used as the default log > > name by systems that do not support named alarm lists." > > ::= { alarmActiveEntry 1 } > > I am not seeing why this object needs to be defined. One could use the > nlmLogName directly in the indexes where alarmListName is used. > The nlmLogName is not-accessible and therefore it is > not needed to implement the NOTIFICATION-LOG-MIB module. > And as it looks the association is needed if the NOTIFICATION-LOG-MIB > exist. > > Neither, I do not fully understand why it is defined in this > table and not in the alarmModelTable. A definition of the alarmListName > in that table looks more logic to me, but I am maybe missing something. > > If the WG wants to keep this object, I do not object. > > > > > alarmActiveDateAndTime OBJECT-TYPE > > DESCRIPTION > > "The local date and time when the error occurred. > > I would drop 'local', as long as it is known in which timezone > the alarm went active it is no problem. For instance, you can have > systems in all timezones, but still using UTC as its timezone. > Then 'local' is not really 'local'. (Also in some others) > > > alarmActiveVariables OBJECT-TYPE > > DESCRIPTION > > "The number of variables in alarmActiveVariableTable for this > > alarm. Also, the number of varbinds for the notification > > associated with this alarm state." > > I beleive that the part 'Also,...' makes it more unclear on the value, > since there is a difference in varbinds between V2 or V1 > trap/notification > PDU. I suggest dropping that. The table refered to, > 'alarmActiveVariableTable', > provides enough information. > > > alarmActiveNotificationID OBJECT-TYPE > > Is this not retrievable from the alarmModelTable by using the > alarmActiveModelPointer?? > > > alarmActiveLogPointer OBJECT-TYPE > > DESCRIPTION > > "A pointer to the corresponding row in a > > notification logging MIB where the state change > > notification for this active alarm is logged. > > If no log entry applies to this active alarm, > > then this object MUST have the value of 0.0" > > For clarity, I suggest using here a specific reference towards the table > in which the log index resides within the MIB. > > > alarmActiveVariableValueType OBJECT-TYPE > > SYNTAX INTEGER { > > counter32(1), > > unsigned32(2), > > timeTicks(3), > > integer32(4), > > ipAddress(5), > > octetString(6), > > objectId(7), > > counter64(8), > > opaque(9) > > } > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The type of the value. One and only one of the value > > objects that follow is used, based on this type." > > Also 'the value' is better described by 'the value of the object > indicated by alarmActiveVariableID'. > The last part I am not sure what an implementor should do. > Should it provide dummy values for the 'not used' variables or > create 'holes' in the table. > > > alarmActiveVariableCounter32Val OBJECT-TYPE > > SYNTAX Counter32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The value when alarmActiveVariableType is 'counter32'." > > ::= { alarmActiveVariableEntry 4 } > > About the 'alarmActiveVariable.....Val' objects it should be noted that > the value has no significance if 'alarmActiveVariableType' is > indicating to > that type/object. > Also 'The value' is better described by 'The value of the object > indicated by alarmActiveVariableID' > > > > > alarmActiveVariableIpAddressVal OBJECT-TYPE > > SYNTAX IpAddress > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The value when alarmActiveVariableType is 'ipAddress'." > > ::= { alarmActiveVariableEntry 9 } > > Not sure what to do here. It is not recommended to use IpAddress as a > type, > but replacing it by InetAddress is neither possible, that would result > in > a alarmActiveVariableOctetStringVal. > Now the question, how can a management station detect which InetAddress > type is used?? > > > -- Statistics -- > > > > alarmActiveStatsActives OBJECT-TYPE > > SYNTAX Counter32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The total number of active alarms since system restarted." > > How is the persistence defined when only the SNMP engine reboots?? > > > alarmClearIndex OBJECT-TYPE > > SYNTAX Unsigned32 (1..4294967295) > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "A strictly monotonically increasing integer which acts > > as the index of entries within the named alarm list. > > It wraps back to 1 after it reaches its maximum value. > > > > This object has the same value as the alarmActiveIndex that > > this alarm instance had when it was active." > > ::= { alarmClearEntry 1 } > > The value will always have the same value as the alarmActiveIndex, but I > believe that alarms will not always be cleared in the same order as they > are active. Thus the requirement of a 'strictly monotonically increasing > integer' is not usefull here (maybe even not possible). > > > > > alarmClearLogIndex OBJECT-TYPE > > SYNTAX Unsigned32 (0..4294967295) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This number MUST be the same as the log index of the > > applicable row in the notification log MIB, if it exists. > > If no log index applies to the trap, then this object > > MUST have the value of 0." > > For clarity, I suggest using here a specific reference towards the table > in which the log index resides. > > > alarmClearState NOTIFICATION-TYPE > > DESCRIPTION > > "An instance of the alarm indicated by > > alarmActiveModelPointer has been cleared against > > the entity indicated by alarmACtiveResourceId." > ^ > 'alarmACtiveResourceId' -> 'alarmActiveResourceId' > > > alarmCompliance MODULE-COMPLIANCE > > STATUS current > > DESCRIPTION > > "The compliance statement for systems supporting > > the Alarm MIB." > > MODULE -- this module > > MANDATORY-GROUPS { > > alarmActiveGroup, > > alarmModelGroup > > } > > ::= { alarmCompliances 1 } > > Since there are read-create objects, the mib-review document indicates > there > should be a FullCompliance and ReadOnlyCompliance statement. > > > 5.1 Overview > > > > This MIB module defines alarm information specific to the alarm > > model defined in ITU M.3100 [M.3100], X.733[X.733] and X.736[X.736]. > > A short description of the ITU Alarm Model would not hurt a reader > its understanding. Perticular, those that cannot access the ITU > standards themselves, like me. > > > ianaItuAlarmNumbers MODULE-IDENTITY > > LAST-UPDATED "200208280000Z" > > ORGANIZATION "IANA" > > CONTACT-INFO > > "Postal: Internet Assigned Numbers Authority > > Internet Corporation for Assigned Names > > > > and Numbers > > nit: little formatting. :-)) > > > ituAlarmActiveServiceUser OBJECT-TYPE > > DESCRIPTION > > "Represents the SericeUser object from [X.736]." > ^ > 'SericeUser' -> 'ServiceUser' > > Maybe the description of the MODULE-IDENTITY should also state that > only values may be added when they are defined by the ITU alarm model. > > > > > ituAlarmActiveStatsIndeterminateCurrent OBJECT-TYPE > > SYNTAX Gauge32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "A count of the current number of active alarms with a > > ituAlarmPerceivedSeverity of indeterminate." > > ::= { ituAlarmActiveStatsEntry 1 } > > Is it the idea to add an extra column for every later added > perceived severity?? Otherwise, the perceived severity > could be an index and the table has just 2 columns > current and total. > > > ituAlarmCompliance MODULE-COMPLIANCE > > STATUS current > > DESCRIPTION > > "The compliance statement for systems supporting > > the ITU Alarm MIB." > > MODULE -- this module > > MANDATORY-GROUPS { > > ituAlarmGroup > > } > > ::= { ituAlarmCompliances 1 } > > Since there are read-write objects, the mib-review document indicates > there > should be a FullCompliance and ReadOnlyCompliance statement. > > > > 6.4 Printer MIB Alarm Example > > > > Consider the following Notifications defined in the > > printer MIB [RFC1759]: > > I understand the problem with copying from another document > for complete definitions, but here are some copied and not all > objects as defined in the OBJECTS-clause of 'printerV2Alert'. > I would suggest add all, or as it seems the most used 'prtAlertGroup' > or none. > > > > > prtAlertSeverityLevel OBJECT-TYPE > > -- This value is a type 1 enumeration > > SYNTAX INTEGER { > > other(1), > > critical(3), > > warning(4) > > } > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The level of severity of this alert table entry. The printer > > determines the severity level assigned to each entry into the > > table." > > ::= { prtAlertEntry 2 } > > > > printerV2Alert NOTIFICATION-TYPE > > OBJECTS { prtAlertIndex, prtAlertSeverityLevel, prtAlertGroup, > > prtAlertGroupIndex, prtAlertLocation, prtAlertCode } > > STATUS current > > DESCRIPTION > > "This trap is sent whenever a critical event is added to the > > prtAlertTable." > > ::= { printerV2AlertPrefix 1 } > > > > 6.5 RMON Alarm Example > > > > alarmModelIndex 6 > > alarmModelState 2 > > alarmModelNotificationId RisingAlarm > > alarmModelVarbindIndex 0 > > alarmModelVarbindValue 0 > > alarmModelDescription "RMON Rising Alarm" > > alarmModelSpecificPointer 0.0 > > alarmModelRowStatus active (1) > > alarmModelVarbindSubtree alarmIndex > > alarmModelResourcePrefix 0.0 > > alarmModelRowStatus active (1) > > Has twice 'alarmModelRowStatus' (first need to be deleted). > > > regards, > > Harrie > From mailnull@www1.ietf.org Wed Mar 19 02:18:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02742 for ; Wed, 19 Mar 2003 02:18:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J7ZWR06451 for disman-archive@odin.ietf.org; Wed, 19 Mar 2003 02:35:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J7ZWO06448 for ; Wed, 19 Mar 2003 02:35:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02202 for ; Wed, 19 Mar 2003 02:17:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J7Z8O06426; Wed, 19 Mar 2003 02:35:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J7YVO06402 for ; Wed, 19 Mar 2003 02:34:31 -0500 Received: from conure.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01404 for ; Wed, 19 Mar 2003 02:16:43 -0500 (EST) Received: from h-68-164-17-66.snvacaid.covad.net ([68.164.17.66] helo=oemcomputer) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18vXqh-0006Gj-00; Tue, 18 Mar 2003 23:18:55 -0800 Message-ID: <016701c2ede8$4b205180$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Jan Engfeldt \(EAB\)" , References: <034BEFD03799D411A59F00508BDF754606C5F452@esealnt448.al.sw.ericsson.se> Subject: Re: [Disman] Patents on MIBs? X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Mar 2003 23:22:26 -0800 Hi - > From: "Jan Engfeldt (EAB)" > To: ; > Sent: Tuesday, March 18, 2003 6:35 AM > Subject: [Disman] Patents on MIBs? > > Hello, > > I been told that the DISMAN MIB is patented by Nortel, is this correct? > > regards > Jan Engfeldt > SPM Management Solutions > Phone:+46850876315 > Mobile: +46702674650 > Fax: +46859436030 There are several different RFCs and internet-drafts produced by the disman working group which contain MIB modules. Nortel Networks submitted a statement (see http://www.ietf.org/ietf/IPR/NORTEL-CHISOLM for details) with respect to , which was an input into the Alarm MIB work, currently returned to the working group after AD-review, soon to be in working group last call once again. I do not know whether Nortel Networks has actually sought patent protection for this technology, I do not know what a patent has been granted, and do I do not know whether they believe that technology is essential for (or even relevant to) implementation of the specification as written in the current internet-draft. Perhaps someone more familiar with Nortel's IPR could comment on these details, or provide a pointer to the patent / application. Since the statement submitted seems to satisfy RFC 2026 section 10.3.2 (c), and since we lack the material (i.e. the patent itself) that would allow working group members to decide for themselves whether is essential or to identify non-infringing alternative implementation strategies, and since there has been no controversy within the WG on this question, I believe there is no action the WG would need to take on this matter at this stage of the process. Randy From mailnull@www1.ietf.org Wed Mar 19 09:26:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21339 for ; Wed, 19 Mar 2003 09:26:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JEhjc00648 for disman-archive@odin.ietf.org; Wed, 19 Mar 2003 09:43:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JEhjO00645 for ; Wed, 19 Mar 2003 09:43:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21329 for ; Wed, 19 Mar 2003 09:25:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JEfDO00570; Wed, 19 Mar 2003 09:41:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JEeUO00538 for ; Wed, 19 Mar 2003 09:40:30 -0500 Received: from mlbmx2.corp.harris.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21293 for ; Wed, 19 Mar 2003 09:22:35 -0500 (EST) Received: by mlbmx2.corp.harris.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Mar 2003 09:24:49 -0500 Message-ID: From: "Donald, Keith" To: "'disman@ietf.org'" Subject: RE: [Disman] question regarding the alarm mib MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Mar 2003 09:24:46 -0500 Randy, Thanks for the response. I agree a log would be an acceptable way to view historical alarms. Thinking back to when I wrote the email, I was concerned an operator would want to see the state history of a single active alarm. For example, that high temperature went from normal->minor, minor->critical, critical->minor, minor->clear would be the history of a single alarm that transitioned through several states over the course of its life. Basicially, I saw the following 'view' as most useful to the operator for historical alarms: 12:00 alarm 'high-temp' active, resource: my_chassis, initial state 'minor' 1:00 alarm state changed to critical 2:00 alarm state changed to minor 3:00 alarm cleared then, sometime later... 5:00 alarm 'high-temp' active, resource: my_chassis, initial state 'critical' 6:00 alarm cleared This is in contrast to this view: 12:00 alarm 'high-temp' minor active, resource: my_chassis 1:00 alarm 'high-temp' critical active, resource: my_chassis 2:00 alarm 'high-temp' minor active, resource: my_chassis 3:00 alarm 'high-temp' cleared active, resource: my_chassis 5:00 alarm 'high-temp' critical active, resource: my_chassis 6:00 alarm 'high-temp' cleared, resource: my_chassis In this typical 'alarm event view', it's more difficult to identify the two alarm conditions on the resource. I still think you need this view, but I was confused as to how one could build the first view above without making the relationship between an alarm and its state transitions more explicit. As you mentioned, a log seems the best place for this. It seems one could use the "alarm active index" to associate an alarm with its state history in a log. For example: 3:00 alarm 'high-temp' active, initial state 'minor', resource: my_chassis -> insert new activeAlarmTable record, assign activeIndex = n, log... 5:00 alarm state changed to critical --> update activeAlarmTable record, log and associate state change with activeIndex == n. 6:00 alarm cleared --> delete activeAlarmTable record, log and associate state change with activeIndex == n. (or something like that...) Thanks, Keith -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Monday, March 17, 2003 1:59 AM To: Disman (E-mail) Subject: Re: [Disman] question regarding the alarm mib Hi - I haven't seen a response to this query, so I've taken a stab at it, in-line below. Perhaps it would make sense address it explicitly in the update to the I-D, which we need to do anyway to address IESG concerns. Comments? Randy > From: "Donald, Keith" > To: "Disman (E-mail)" > Sent: Wednesday, February 19, 2003 11:06 AM > Subject: [Disman] question regarding the alarm mib > > I have a question regarding a semantic of the alarm mib that I can't find > directly discussed in the RFC: > > What is the expected behaivior when an active alarm transitions to another > active state? (as opposed to a clear state.) I see a couple of different > possibilities and was wondering which one is the right one: > > 1. The previously active state is moved to the "cleared" alarm table to > note it as a "historical" alarm. The new active state is added to the > activeAlarm table. > - The problem with this approach is it looks like their are two > different alarms (and one has cleared), when in reality there is only one alarm > that has transitioned from one active state to another over the course of its > life. I think this is *not* intended. The description of alarmClearTable and its columns makes it (relatively) clear that only a cleared alarm (alarmModelState value 1) would go there. > 2. The new active alarm state simply "replaces" the previously active > alarm state in the alarmActive table. > - The problem here is you lose information about the previous > alarm state. This option seems unacceptable. I believe this is the intent. I don't see why it would be unacceptable. If one cared about previous alarms, a log (as in RFC 3014) would seem to be a more appropriate mechanism. > 3. The new active alarm state replaces the previous state, and the > previous state is added as a "historical" state for that active alarm instance. > - This seems like the best solution, but is this supported by > the current model? No. > Here is an example of what I mean: > > Suppose a simple "Temperature" alarm model exists and has states of: > Temperature Normal (clear) > Temperature Minor > Temperature Major > Temperature Critical > > When a "Temperature Minor" alarm condition is detected, the alarm is added to > the activeAlarm table and any triggering event information is associated with > it. What happens when if the alarm transitions from Minor to Major, or from > Minor to Critical? Should one activeAlarm instance track these state > transitions explicitly over the course of its life? Or is each state transition > viewed as a separate alarm? Let's be careful with the terminology. There would be a single "active alarm" which would reflect the severity levels associated with the various alarms (in the X.733 sense) processed. > Thank you for your help, > > Keith Donald > kdonald@harris.com > From mailnull@www1.ietf.org Wed Mar 19 16:11:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08369 for ; Wed, 19 Mar 2003 16:11:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JLT0j05300 for disman-archive@odin.ietf.org; Wed, 19 Mar 2003 16:29:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLT0O05297 for ; Wed, 19 Mar 2003 16:29:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08361 for ; Wed, 19 Mar 2003 16:10:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLQSO05163; Wed, 19 Mar 2003 16:26:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JCuBO25770 for ; Wed, 19 Mar 2003 07:56:11 -0500 Received: from tomts12-srv.bellnexxia.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19658 for ; Wed, 19 Mar 2003 07:38:19 -0500 (EST) Received: from DCR8PM11 ([64.230.125.69]) by tomts12-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20030319124033.HRTQ13063.tomts12-srv.bellnexxia.net@DCR8PM11>; Wed, 19 Mar 2003 07:40:33 -0500 Message-ID: <001401c2ee14$bae128b0$0de5fea9@DCR8PM11> From: "NorthWhite" To: "Randy Presuhn" , "Jan Engfeldt \(EAB\)" , References: <034BEFD03799D411A59F00508BDF754606C5F452@esealnt448.al.sw.ericsson.se> <016701c2ede8$4b205180$7f1afea9@oemcomputer> Subject: Re: [Disman] Patents on MIBs? 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Mar 2003 07:40:31 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I co-authored one of the patents related to this when I worked in Nortel 1999. The patent is filed in US. The ideas patented are - TMN & SNMP integration - Method for recover lost traps (if I remembered clearly) Forget the reason why we patent it, Nortel encourages employees to patent everything at that time. NW http://www3.sympatico.ca/northwhite/ > I do not know whether Nortel Networks has actually sought patent protection for this > technology, I do not know what a patent has been granted, and do I do not know > whether they believe that technology is essential for (or even relevant to) implementation > of the specification as written in the current internet-draft. > From disman-admin@ietf.org Wed Mar 19 22:57:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22971 for ; Wed, 19 Mar 2003 22:57:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K4EEO05381; Wed, 19 Mar 2003 23:14:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K4C6O05267 for ; Wed, 19 Mar 2003 23:12:06 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22890 for ; Wed, 19 Mar 2003 22:53:54 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2K3u8Z03548 for ; Wed, 19 Mar 2003 22:56:09 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Mar 2003 04:56:07 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155012721EE@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Disman (E-mail) (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Disman] reclassifying to Historic Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Mar 2003 04:56:07 +0100 Checked with IESG... and silly as it sounds, the trend seems to be that we indeed need to do an informational RFC to explain why. See for example RFC3197 Bert From mailnull@www1.ietf.org Wed Mar 19 22:57:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22996 for ; Wed, 19 Mar 2003 22:57:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K4FG705489 for disman-archive@odin.ietf.org; Wed, 19 Mar 2003 23:15:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K4FFO05486 for ; Wed, 19 Mar 2003 23:15:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22974 for ; Wed, 19 Mar 2003 22:57:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K4EEO05381; Wed, 19 Mar 2003 23:14:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K4C6O05267 for ; Wed, 19 Mar 2003 23:12:06 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22890 for ; Wed, 19 Mar 2003 22:53:54 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2K3u8Z03548 for ; Wed, 19 Mar 2003 22:56:09 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Mar 2003 04:56:07 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155012721EE@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Disman (E-mail) (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Disman] reclassifying to Historic Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Mar 2003 04:56:07 +0100 Checked with IESG... and silly as it sounds, the trend seems to be that we indeed need to do an informational RFC to explain why. See for example RFC3197 Bert From disman-admin@ietf.org Thu Mar 20 02:03:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01590 for ; Thu, 20 Mar 2003 02:03:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K7KIO28401; Thu, 20 Mar 2003 02:20:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K7GdO28237 for ; Thu, 20 Mar 2003 02:16:39 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28276 for ; Thu, 20 Mar 2003 01:58:05 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2K70G4c023917; Wed, 19 Mar 2003 23:00:16 -0800 (PST) Received: from cisco.com (sjc-vpn4-811.cisco.com [10.21.83.42]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AFH52804; Wed, 19 Mar 2003 22:59:00 -0800 (PST) Message-ID: <3E796700.4AC3FC2F@cisco.com> From: Ram Kavasseri X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: "Disman (E-mail) (E-mail)" Subject: Re: [Disman] reclassifying to Historic References: <7D5D48D2CAA3D84C813F5B154F43B155012721EE@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Mar 2003 23:00:16 -0800 Content-Transfer-Encoding: 7bit For those not at the Disman WG meeting today, Bert is referring to moving the Expression MIB to historical status... Ram Kavasseri "Wijnen, Bert (Bert)" wrote: > Checked with IESG... and silly as it sounds, > the trend seems to be that we indeed need to do > an informational RFC to explain why. > > See for example RFC3197 > > Bert From mailnull@www1.ietf.org Thu Mar 20 02:03:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01944 for ; Thu, 20 Mar 2003 02:03:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K7LC628877 for disman-archive@odin.ietf.org; Thu, 20 Mar 2003 02:21:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K7L2O28493 for ; Thu, 20 Mar 2003 02:21:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00994 for ; Thu, 20 Mar 2003 02:02:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K7KIO28401; Thu, 20 Mar 2003 02:20:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K7GdO28237 for ; Thu, 20 Mar 2003 02:16:39 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28276 for ; Thu, 20 Mar 2003 01:58:05 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2K70G4c023917; Wed, 19 Mar 2003 23:00:16 -0800 (PST) Received: from cisco.com (sjc-vpn4-811.cisco.com [10.21.83.42]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AFH52804; Wed, 19 Mar 2003 22:59:00 -0800 (PST) Message-ID: <3E796700.4AC3FC2F@cisco.com> From: Ram Kavasseri X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: "Disman (E-mail) (E-mail)" Subject: Re: [Disman] reclassifying to Historic References: <7D5D48D2CAA3D84C813F5B154F43B155012721EE@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Mar 2003 23:00:16 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit For those not at the Disman WG meeting today, Bert is referring to moving the Expression MIB to historical status... Ram Kavasseri "Wijnen, Bert (Bert)" wrote: > Checked with IESG... and silly as it sounds, > the trend seems to be that we indeed need to do > an informational RFC to explain why. > > See for example RFC3197 > > Bert From disman-admin@ietf.org Thu Mar 20 11:03:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22892 for ; Thu, 20 Mar 2003 11:03:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KGLBO30868; Thu, 20 Mar 2003 11:21:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KGHjO30584 for ; Thu, 20 Mar 2003 11:17:45 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22708 for ; Thu, 20 Mar 2003 10:59:19 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2KG1X917910 for ; Thu, 20 Mar 2003 11:01:33 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Mar 2003 17:01:32 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501272405@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Ram Kavasseri , "Wijnen, Bert (Bert)" Cc: "Disman (E-mail) (E-mail)" Subject: RE: [Disman] reclassifying to Historic MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Mar 2003 17:01:30 +0100 Right... and my email was only meant to explain how we need to do it if we decide to indeed do it. The most quoted reason is that we want to document our (IETF) actions/decisions and making it an RFC ensures it does not get lost. Some IESG members do remember that various RFCs were re-classified long time ago... but they no longer remember the exact arguments as to why that was done. Thanks, Bert > -----Original Message----- > From: Ram Kavasseri [mailto:ramk@cisco.com] > Sent: donderdag 20 maart 2003 8:00 > To: Wijnen, Bert (Bert) > Cc: Disman (E-mail) (E-mail) > Subject: Re: [Disman] reclassifying to Historic > > > For those not at the Disman WG meeting today, Bert is > referring to moving the Expression MIB to historical > status... > > Ram Kavasseri > > "Wijnen, Bert (Bert)" wrote: > > > Checked with IESG... and silly as it sounds, > > the trend seems to be that we indeed need to do > > an informational RFC to explain why. > > > > See for example RFC3197 > > > > Bert > From mailnull@www1.ietf.org Thu Mar 20 11:04:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22975 for ; Thu, 20 Mar 2003 11:04:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KGMFI30989 for disman-archive@odin.ietf.org; Thu, 20 Mar 2003 11:22:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KGMFO30986 for ; Thu, 20 Mar 2003 11:22:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22895 for ; Thu, 20 Mar 2003 11:03:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KGLBO30868; Thu, 20 Mar 2003 11:21:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KGHjO30584 for ; Thu, 20 Mar 2003 11:17:45 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22708 for ; Thu, 20 Mar 2003 10:59:19 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2KG1X917910 for ; Thu, 20 Mar 2003 11:01:33 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Mar 2003 17:01:32 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501272405@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Ram Kavasseri , "Wijnen, Bert (Bert)" Cc: "Disman (E-mail) (E-mail)" Subject: RE: [Disman] reclassifying to Historic MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Mar 2003 17:01:30 +0100 Right... and my email was only meant to explain how we need to do it if we decide to indeed do it. The most quoted reason is that we want to document our (IETF) actions/decisions and making it an RFC ensures it does not get lost. Some IESG members do remember that various RFCs were re-classified long time ago... but they no longer remember the exact arguments as to why that was done. Thanks, Bert > -----Original Message----- > From: Ram Kavasseri [mailto:ramk@cisco.com] > Sent: donderdag 20 maart 2003 8:00 > To: Wijnen, Bert (Bert) > Cc: Disman (E-mail) (E-mail) > Subject: Re: [Disman] reclassifying to Historic > > > For those not at the Disman WG meeting today, Bert is > referring to moving the Expression MIB to historical > status... > > Ram Kavasseri > > "Wijnen, Bert (Bert)" wrote: > > > Checked with IESG... and silly as it sounds, > > the trend seems to be that we indeed need to do > > an informational RFC to explain why. > > > > See for example RFC3197 > > > > Bert > From mailnull@www1.ietf.org Thu Mar 20 12:03:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24807 for ; Thu, 20 Mar 2003 12:03:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KHLWk06467 for disman-archive@odin.ietf.org; Thu, 20 Mar 2003 12:21:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KHLWO06464 for ; Thu, 20 Mar 2003 12:21:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24794 for ; Thu, 20 Mar 2003 12:03:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KHL8O06441; Thu, 20 Mar 2003 12:21:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KH8rO05603 for ; Thu, 20 Mar 2003 12:08:53 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24274 for ; Thu, 20 Mar 2003 11:50:26 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2KGqd920147 for ; Thu, 20 Mar 2003 11:52:40 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Mar 2003 17:52:39 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501272425@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Disman (E-mail) (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Disman] FW: Another process question Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Mar 2003 17:52:38 +0100 Here is another (valid I think) thought: > The explanation is that it has only been implemented by > one vendor and that vendor's author is not sure they > still use it (he will check). so why bother? if its not hurting anyone what is gained by moving it to historic? in my mind random moving of things to historic when they are not causing any problem dilutes the usefulness of historic as a warning sign. Scott From disman-admin@ietf.org Thu Mar 20 12:03:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24826 for ; Thu, 20 Mar 2003 12:03:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KHL8O06441; Thu, 20 Mar 2003 12:21:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KH8rO05603 for ; Thu, 20 Mar 2003 12:08:53 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24274 for ; Thu, 20 Mar 2003 11:50:26 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2KGqd920147 for ; Thu, 20 Mar 2003 11:52:40 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Mar 2003 17:52:39 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501272425@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Disman (E-mail) (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Disman] FW: Another process question Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Mar 2003 17:52:38 +0100 Here is another (valid I think) thought: > The explanation is that it has only been implemented by > one vendor and that vendor's author is not sure they > still use it (he will check). so why bother? if its not hurting anyone what is gained by moving it to historic? in my mind random moving of things to historic when they are not causing any problem dilutes the usefulness of historic as a warning sign. Scott From disman-admin@ietf.org Thu Mar 20 12:12:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25409 for ; Thu, 20 Mar 2003 12:12:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KHU4O07324; Thu, 20 Mar 2003 12:30:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KHT6O07239 for ; Thu, 20 Mar 2003 12:29:06 -0500 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25334 for ; Thu, 20 Mar 2003 12:10:38 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2KHAdmU014465; Thu, 20 Mar 2003 09:10:46 -0800 (PST) Received: from cisco.com (sjc-vpn4-811.cisco.com [10.21.83.42]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AFH78511; Thu, 20 Mar 2003 09:09:20 -0800 (PST) Message-ID: <3E79F60D.DDE2B85E@cisco.com> From: Ram Kavasseri X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: "Disman (E-mail) (E-mail)" Subject: Re: [Disman] reclassifying to Historic References: <7D5D48D2CAA3D84C813F5B154F43B15501272405@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Mar 2003 09:10:37 -0800 Content-Transfer-Encoding: 7bit Sounds good to me. While it's a slight pain to document, it captures "implementation experience" in case someone revives the exact same idea a few years down the road. :-) Ram "Wijnen, Bert (Bert)" wrote: > Right... and my email was only meant to explain > how we need to do it if we decide to indeed do it. > > The most quoted reason is that we want to document > our (IETF) actions/decisions and making it an RFC > ensures it does not get lost. > > Some IESG members do remember that various RFCs were > re-classified long time ago... but they no longer > remember the exact arguments as to why that was done. > > Thanks, > Bert > > > -----Original Message----- > > From: Ram Kavasseri [mailto:ramk@cisco.com] > > Sent: donderdag 20 maart 2003 8:00 > > To: Wijnen, Bert (Bert) > > Cc: Disman (E-mail) (E-mail) > > Subject: Re: [Disman] reclassifying to Historic > > > > > > For those not at the Disman WG meeting today, Bert is > > referring to moving the Expression MIB to historical > > status... > > > > Ram Kavasseri > > > > "Wijnen, Bert (Bert)" wrote: > > > > > Checked with IESG... and silly as it sounds, > > > the trend seems to be that we indeed need to do > > > an informational RFC to explain why. > > > > > > See for example RFC3197 > > > > > > Bert > > From disman-admin@ietf.org Thu Mar 20 12:12:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25415 for ; Thu, 20 Mar 2003 12:12:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KHU6O07340; Thu, 20 Mar 2003 12:30:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KHT8O07243 for ; Thu, 20 Mar 2003 12:29:08 -0500 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25337 for ; Thu, 20 Mar 2003 12:10:40 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2KHCfmU016276; Thu, 20 Mar 2003 09:12:42 -0800 (PST) Received: from cisco.com (sjc-vpn4-811.cisco.com [10.21.83.42]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AFH78710; Thu, 20 Mar 2003 09:11:22 -0800 (PST) Message-ID: <3E79F687.8761A0B9@cisco.com> From: Ram Kavasseri X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: "Disman (E-mail) (E-mail)" Subject: Re: [Disman] FW: Another process question References: <7D5D48D2CAA3D84C813F5B154F43B15501272425@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Mar 2003 09:12:39 -0800 Content-Transfer-Encoding: 7bit "Wijnen, Bert (Bert)" wrote: > Here is another (valid I think) thought: > > The explanation is that it has only been implemented by > > one vendor and that vendor's author is not sure they > > still use it (he will check). > > so why bother? > > if its not hurting anyone what is gained by moving it to historic? > > in my mind random moving of things to historic when they > are not causing any problem dilutes the usefulness of historic > as a warning sign. > > Scott A few years down the road, if someone else has the same idea, you'd have documented experience that can be referred - even after DISMAN's charter is through. Ram From mailnull@www1.ietf.org Thu Mar 20 12:13:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25464 for ; Thu, 20 Mar 2003 12:13:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KHV2E07462 for disman-archive@odin.ietf.org; Thu, 20 Mar 2003 12:31:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KHV2O07459 for ; Thu, 20 Mar 2003 12:31:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25412 for ; Thu, 20 Mar 2003 12:12:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KHU4O07324; Thu, 20 Mar 2003 12:30:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KHT6O07239 for ; Thu, 20 Mar 2003 12:29:06 -0500 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25334 for ; Thu, 20 Mar 2003 12:10:38 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2KHAdmU014465; Thu, 20 Mar 2003 09:10:46 -0800 (PST) Received: from cisco.com (sjc-vpn4-811.cisco.com [10.21.83.42]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AFH78511; Thu, 20 Mar 2003 09:09:20 -0800 (PST) Message-ID: <3E79F60D.DDE2B85E@cisco.com> From: Ram Kavasseri X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: "Disman (E-mail) (E-mail)" Subject: Re: [Disman] reclassifying to Historic References: <7D5D48D2CAA3D84C813F5B154F43B15501272405@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Mar 2003 09:10:37 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sounds good to me. While it's a slight pain to document, it captures "implementation experience" in case someone revives the exact same idea a few years down the road. :-) Ram "Wijnen, Bert (Bert)" wrote: > Right... and my email was only meant to explain > how we need to do it if we decide to indeed do it. > > The most quoted reason is that we want to document > our (IETF) actions/decisions and making it an RFC > ensures it does not get lost. > > Some IESG members do remember that various RFCs were > re-classified long time ago... but they no longer > remember the exact arguments as to why that was done. > > Thanks, > Bert > > > -----Original Message----- > > From: Ram Kavasseri [mailto:ramk@cisco.com] > > Sent: donderdag 20 maart 2003 8:00 > > To: Wijnen, Bert (Bert) > > Cc: Disman (E-mail) (E-mail) > > Subject: Re: [Disman] reclassifying to Historic > > > > > > For those not at the Disman WG meeting today, Bert is > > referring to moving the Expression MIB to historical > > status... > > > > Ram Kavasseri > > > > "Wijnen, Bert (Bert)" wrote: > > > > > Checked with IESG... and silly as it sounds, > > > the trend seems to be that we indeed need to do > > > an informational RFC to explain why. > > > > > > See for example RFC3197 > > > > > > Bert > > From mailnull@www1.ietf.org Thu Mar 20 13:11:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25467 for ; Thu, 20 Mar 2003 12:13:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KHV3D07478 for disman-archive@odin.ietf.org; Thu, 20 Mar 2003 12:31:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KHV3O07475 for ; Thu, 20 Mar 2003 12:31:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25425 for ; Thu, 20 Mar 2003 12:12:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KHU6O07340; Thu, 20 Mar 2003 12:30:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KHT8O07243 for ; Thu, 20 Mar 2003 12:29:08 -0500 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25337 for ; Thu, 20 Mar 2003 12:10:40 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2KHCfmU016276; Thu, 20 Mar 2003 09:12:42 -0800 (PST) Received: from cisco.com (sjc-vpn4-811.cisco.com [10.21.83.42]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AFH78710; Thu, 20 Mar 2003 09:11:22 -0800 (PST) Message-ID: <3E79F687.8761A0B9@cisco.com> From: Ram Kavasseri X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: "Disman (E-mail) (E-mail)" Subject: Re: [Disman] FW: Another process question References: <7D5D48D2CAA3D84C813F5B154F43B15501272425@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Mar 2003 09:12:39 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Wijnen, Bert (Bert)" wrote: > Here is another (valid I think) thought: > > The explanation is that it has only been implemented by > > one vendor and that vendor's author is not sure they > > still use it (he will check). > > so why bother? > > if its not hurting anyone what is gained by moving it to historic? > > in my mind random moving of things to historic when they > are not causing any problem dilutes the usefulness of historic > as a warning sign. > > Scott A few years down the road, if someone else has the same idea, you'd have documented experience that can be referred - even after DISMAN's charter is through. Ram From mailnull@www1.ietf.org Sun Mar 23 18:01:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13285 for ; Sun, 23 Mar 2003 18:01:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2NNLBK02695 for disman-archive@odin.ietf.org; Sun, 23 Mar 2003 18:21:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NNLBO02692 for ; Sun, 23 Mar 2003 18:21:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13248 for ; Sun, 23 Mar 2003 18:01:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NNKYO02655; Sun, 23 Mar 2003 18:20:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NNHlO02581 for ; Sun, 23 Mar 2003 18:17:47 -0500 Received: from hawk.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13090 for ; Sun, 23 Mar 2003 17:57:45 -0500 (EST) Received: from h-68-164-79-161.snvacaid.covad.net ([68.164.79.161] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18xERe-0003Hq-00 for disman@ietf.org; Sun, 23 Mar 2003 15:00:02 -0800 Message-ID: <014301c2f190$67fe5120$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Disman] Link to freely available ISO documents Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Mar 2003 15:03:23 -0800 Hi - Here is a useful URL. Click on the link "Proceed to public areas" on this page: http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm Randy From disman-admin@ietf.org Sun Mar 23 18:01:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13298 for ; Sun, 23 Mar 2003 18:01:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NNKYO02655; Sun, 23 Mar 2003 18:20:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NNHlO02581 for ; Sun, 23 Mar 2003 18:17:47 -0500 Received: from hawk.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13090 for ; Sun, 23 Mar 2003 17:57:45 -0500 (EST) Received: from h-68-164-79-161.snvacaid.covad.net ([68.164.79.161] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18xERe-0003Hq-00 for disman@ietf.org; Sun, 23 Mar 2003 15:00:02 -0800 Message-ID: <014301c2f190$67fe5120$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Disman] Link to freely available ISO documents Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Mar 2003 15:03:23 -0800 Hi - Here is a useful URL. Click on the link "Proceed to public areas" on this page: http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm Randy From mailnull@www1.ietf.org Mon Mar 24 01:37:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23579 for ; Mon, 24 Mar 2003 01:37:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2O6v3g28776 for disman-archive@odin.ietf.org; Mon, 24 Mar 2003 01:57:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O6v3O28773 for ; Mon, 24 Mar 2003 01:57:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23574 for ; Mon, 24 Mar 2003 01:36:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O6udO28760; Mon, 24 Mar 2003 01:56:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O6rwO28703 for ; Mon, 24 Mar 2003 01:53:58 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23550; Mon, 24 Mar 2003 01:33:46 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2O6a04e002014; Sun, 23 Mar 2003 22:36:02 -0800 (PST) Received: from cisco.com (sjc-vpn4-523.cisco.com [10.21.82.11]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AFJ83071; Sun, 23 Mar 2003 22:34:33 -0800 (PST) Message-ID: <3E7EA74F.589790EB@cisco.com> From: Ram Kavasseri X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: minutes@ietf.org CC: disman@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Disman] Minutes from the Disman WG meeting on Wednesday, March 19th, 2003 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Mar 2003 22:35:59 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Disman WG Minutes from the 56th IETF - reported by Ramanathan Kavasseri (ramk@cisco.com) 1. Sharon Chisholm tasked with drafting a "Thank You" message to the ITU-T Liaison, and sending the draft to the DISMAN wg. 2. Sharon will look for any cases where we missed carrying over range constraints into the Alarm MIB docs... 3. Need to wordsmith the description of AlarmResourceID on the mailing list 4. Need to add language describing the persistence of the alarm model table. Also need to determine whether the lang reg persistence is in terms of MUST . That was believed to be the consensus in the past - need to reverify the consensus on the mailing list. 5. Timeframe for finishing Alarm MIB edits (and discussion) - end of March 2003. Updated I-D to appear in April. 6. Hing-Kam Lam needs to look at latest version of ID nits doc, the update to the RFC authors guidelines - for the ARC MIB update, as well as the latest guidelines for MIB reviewers. 7. Kam to make known edits to ARC from above tasks, and send it to Bert and internet-drafts... 8. For Script MIB and Schedule MIB - Randy to look at a questionnaire for implementation requests on these MIBs. 9. Remops MIB - if anyone is interested in assiting with edits, to contact RP on the disman mailing list. 10. Octet String in Remops MIB for payload - has a constraint related to ipv4 - computes pkt size - ipv4 hdr size. Need description clarification on what the object should do (return an error or silently truncate payload size) when transport type is ipv6 - Randy Presuhn suggested silently truncating. Need further discussion on the mailing list. This action item is assigned to Randy Presunhn. 10. Ram Kavasseri to initiate thread on taking Expression MIB to historic status 11. Bert to check whether a doc recommending historic status for Expr MIB is reqd. 12. Need interoperability results (for event and notif-log mibs) summary on wg mailing list. Ram Kavasseri to drive the interoperability test effort. Results need to be posted to the wg by May. 13. NetSNMP implements the EVENT-MIB - this MIB is the target of internal polling for NetSNMP apps. Wes Hardaker to provide pointers on how to set up a copy of NetSNMP running the EVENT-MIB for interoperability testing. 14. Sharon to check and report back on implementations of log MIB at Nortel. 15. Updates for Expr, Event, Notif-Log MIB expected by April 1st. Editor needs to look at latest version of ID nits doc, the update to the RFC authors guidelines - for the ARC MIB update, as well as the latest guidelines for MIB reviewers. 16. Ram to repost implementation requests for the event, expression and notif-log mibs on the disman wg. From disman-admin@ietf.org Mon Mar 24 01:37:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23593 for ; Mon, 24 Mar 2003 01:37:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O6udO28760; Mon, 24 Mar 2003 01:56:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O6rwO28703 for ; Mon, 24 Mar 2003 01:53:58 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23550; Mon, 24 Mar 2003 01:33:46 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2O6a04e002014; Sun, 23 Mar 2003 22:36:02 -0800 (PST) Received: from cisco.com (sjc-vpn4-523.cisco.com [10.21.82.11]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AFJ83071; Sun, 23 Mar 2003 22:34:33 -0800 (PST) Message-ID: <3E7EA74F.589790EB@cisco.com> From: Ram Kavasseri X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: minutes@ietf.org CC: disman@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Disman] Minutes from the Disman WG meeting on Wednesday, March 19th, 2003 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Mar 2003 22:35:59 -0800 Content-Transfer-Encoding: 7bit Disman WG Minutes from the 56th IETF - reported by Ramanathan Kavasseri (ramk@cisco.com) 1. Sharon Chisholm tasked with drafting a "Thank You" message to the ITU-T Liaison, and sending the draft to the DISMAN wg. 2. Sharon will look for any cases where we missed carrying over range constraints into the Alarm MIB docs... 3. Need to wordsmith the description of AlarmResourceID on the mailing list 4. Need to add language describing the persistence of the alarm model table. Also need to determine whether the lang reg persistence is in terms of MUST . That was believed to be the consensus in the past - need to reverify the consensus on the mailing list. 5. Timeframe for finishing Alarm MIB edits (and discussion) - end of March 2003. Updated I-D to appear in April. 6. Hing-Kam Lam needs to look at latest version of ID nits doc, the update to the RFC authors guidelines - for the ARC MIB update, as well as the latest guidelines for MIB reviewers. 7. Kam to make known edits to ARC from above tasks, and send it to Bert and internet-drafts... 8. For Script MIB and Schedule MIB - Randy to look at a questionnaire for implementation requests on these MIBs. 9. Remops MIB - if anyone is interested in assiting with edits, to contact RP on the disman mailing list. 10. Octet String in Remops MIB for payload - has a constraint related to ipv4 - computes pkt size - ipv4 hdr size. Need description clarification on what the object should do (return an error or silently truncate payload size) when transport type is ipv6 - Randy Presuhn suggested silently truncating. Need further discussion on the mailing list. This action item is assigned to Randy Presunhn. 10. Ram Kavasseri to initiate thread on taking Expression MIB to historic status 11. Bert to check whether a doc recommending historic status for Expr MIB is reqd. 12. Need interoperability results (for event and notif-log mibs) summary on wg mailing list. Ram Kavasseri to drive the interoperability test effort. Results need to be posted to the wg by May. 13. NetSNMP implements the EVENT-MIB - this MIB is the target of internal polling for NetSNMP apps. Wes Hardaker to provide pointers on how to set up a copy of NetSNMP running the EVENT-MIB for interoperability testing. 14. Sharon to check and report back on implementations of log MIB at Nortel. 15. Updates for Expr, Event, Notif-Log MIB expected by April 1st. Editor needs to look at latest version of ID nits doc, the update to the RFC authors guidelines - for the ARC MIB update, as well as the latest guidelines for MIB reviewers. 16. Ram to repost implementation requests for the event, expression and notif-log mibs on the disman wg. From mailnull@www1.ietf.org Wed Mar 26 13:22:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06117 for ; Wed, 26 Mar 2003 13:22:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QIhRR20817 for disman-archive@odin.ietf.org; Wed, 26 Mar 2003 13:43:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIhRO20814 for ; Wed, 26 Mar 2003 13:43:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06106 for ; Wed, 26 Mar 2003 13:22:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIgjO20772; Wed, 26 Mar 2003 13:42:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIfoO20746 for ; Wed, 26 Mar 2003 13:41:50 -0500 Received: from turkey.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06075 for ; Wed, 26 Mar 2003 13:20:24 -0500 (EST) Received: from h-68-164-29-130.snvacaid.covad.net ([68.164.29.130] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18yFXu-0000kF-00; Wed, 26 Mar 2003 10:22:42 -0800 Message-ID: <001401c2f3c4$ce00e560$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: "Randy Bush \(E-mail\)" , "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Disman] Report of disman WG session at San Francisco IETF meeting Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 10:23:31 -0800 Hi - Here's the mandatory paragraph: The disman working group met for one session on Wednesday afternoon at the San Francisco IETF meeting. Key topics covered were liaison statements from the ITU Study Group 4, AD review comments on the alarm work, and the question of whether to request that Expression MIB be made historic. We should have this work wrapped up within a few weeks, and do not see a need for an interim meeting at this time. Randy Presuhn From disman-admin@ietf.org Wed Mar 26 13:22:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06131 for ; Wed, 26 Mar 2003 13:22:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIgjO20772; Wed, 26 Mar 2003 13:42:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIfoO20746 for ; Wed, 26 Mar 2003 13:41:50 -0500 Received: from turkey.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06075 for ; Wed, 26 Mar 2003 13:20:24 -0500 (EST) Received: from h-68-164-29-130.snvacaid.covad.net ([68.164.29.130] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18yFXu-0000kF-00; Wed, 26 Mar 2003 10:22:42 -0800 Message-ID: <001401c2f3c4$ce00e560$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: "Randy Bush \(E-mail\)" , "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Disman] Report of disman WG session at San Francisco IETF meeting Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 10:23:31 -0800 Hi - Here's the mandatory paragraph: The disman working group met for one session on Wednesday afternoon at the San Francisco IETF meeting. Key topics covered were liaison statements from the ITU Study Group 4, AD review comments on the alarm work, and the question of whether to request that Expression MIB be made historic. We should have this work wrapped up within a few weeks, and do not see a need for an interim meeting at this time. Randy Presuhn From mailnull@www1.ietf.org Wed Mar 26 13:45:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06869 for ; Wed, 26 Mar 2003 13:45:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QJ6WF22155 for disman-archive@odin.ietf.org; Wed, 26 Mar 2003 14:06:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJ6WO22152 for ; Wed, 26 Mar 2003 14:06:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06855 for ; Wed, 26 Mar 2003 13:45:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJ64O22112; Wed, 26 Mar 2003 14:06:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJ3pO22006 for ; Wed, 26 Mar 2003 14:03:51 -0500 Received: from swan.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06803 for ; Wed, 26 Mar 2003 13:42:25 -0500 (EST) Received: from h-68-164-29-130.snvacaid.covad.net ([68.164.29.130] helo=oemcomputer) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18yFtG-0006Lq-00 for disman@ietf.org; Wed, 26 Mar 2003 10:44:46 -0800 Message-ID: <001701c2f3c7$dfae9fc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Disman] RFC 2595: pingCtlDataSize Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 10:45:29 -0800 Hi - This is action item #10 from the minutes of our session in San Francisco. Currently, RFC 2925 says: pingCtlDataSize OBJECT-TYPE SYNTAX Unsigned32 (0..65507) UNITS "octets" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the size of the data portion to be transmitted in a ping operation in octets. A ping request is usually an ICMP message encoded into an IP packet. An IP packet has a maximum size of 65535 octets. Subtracting the size of the ICMP or UDP header (both 8 octets) and the size of the IP header (20 octets) yields a maximum size of 65507 octets." DEFVAL { 0 } ::= { pingCtlEntry 5 } This has caused some concern that the MIB isn't right for IPv6. As a technical contributor, I'd like to propose the following as a clarification, and would selcome feedback, especially from those who have implemented this in IPv6 environments: DESCRIPTION "Specifies the size of the data portion to be transmitted in a ping operation in octets. A ping request is usually an ICMP message encoded into an IP packet. An IPv4 packet has a maximum size of 65535 octets. Subtracting the size of the ICMP or UDP header (both 8 octets) and the size of the IP header (20 octets) yields a maximum size of 65507 octets for IPv4 environments. If the protocol implied by the value of pingCtlTargetAddressType further limits the size of the data portion, the data is silently truncated to meet those constraints, without affecting the value reported by this object." Again, since I haven't implemented this, I'd really welcome feedback on this proposal from those who have. Randy Presuhn From mailnull@www1.ietf.org Wed Mar 26 14:20:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08247 for ; Wed, 26 Mar 2003 14:20:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QJfUk25701 for disman-archive@odin.ietf.org; Wed, 26 Mar 2003 14:41:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJfUO25698 for ; Wed, 26 Mar 2003 14:41:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08238 for ; Wed, 26 Mar 2003 14:20:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJf3O25683; Wed, 26 Mar 2003 14:41:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJewO25666 for ; Wed, 26 Mar 2003 14:40:58 -0500 Received: from swan.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08198 for ; Wed, 26 Mar 2003 14:19:31 -0500 (EST) Received: from h-68-164-29-130.snvacaid.covad.net ([68.164.29.130] helo=oemcomputer) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18yGT9-0001xN-00 for disman@ietf.org; Wed, 26 Mar 2003 11:21:51 -0800 Message-ID: <004101c2f3cd$09e14a40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Disman] Editors for update to RFC 2595 (remops) Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 11:22:27 -0800 Hi - I'm happy to report that action item #9 from the disman minutes has been resolved. From a field of several amply-qualified volunteers, for the updates to RFC 2595 (remote operations), as WG chair I'm naming Juergen Quittek co-editor. I'd like to offer profuse thanks to the original author and editor, Ken White, for a job well done. Randy From mailnull@www1.ietf.org Wed Mar 26 14:22:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08335 for ; Wed, 26 Mar 2003 14:22:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QJhho25861 for disman-archive@odin.ietf.org; Wed, 26 Mar 2003 14:43:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJhhO25856 for ; Wed, 26 Mar 2003 14:43:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08329 for ; Wed, 26 Mar 2003 14:22:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJhAO25837; Wed, 26 Mar 2003 14:43:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJgsO25795 for ; Wed, 26 Mar 2003 14:42:54 -0500 Received: from swan.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08302 for ; Wed, 26 Mar 2003 14:21:27 -0500 (EST) Received: from h-68-164-29-130.snvacaid.covad.net ([68.164.29.130] helo=oemcomputer) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18yGV2-0005Q8-00 for disman@ietf.org; Wed, 26 Mar 2003 11:23:48 -0800 Message-ID: <004b01c2f3cd$4ec258c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Disman] Re: Editors for update to RFC 2595 (remops) Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 11:24:23 -0800 Hi - > From: "Randy Presuhn" > To: "Disman (E-mail)" > Sent: Wednesday, March 26, 2003 11:22 AM > Subject: Editors for update to RFC 2595 (remops) ... Arrrrghhhh! Make that 2925! Randy From mailnull@www1.ietf.org Wed Mar 26 19:24:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24650 for ; Wed, 26 Mar 2003 19:24:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R0jgH18096 for disman-archive@odin.ietf.org; Wed, 26 Mar 2003 19:45:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R0jfO18093 for ; Wed, 26 Mar 2003 19:45:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24634 for ; Wed, 26 Mar 2003 19:24:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R0jCO18081; Wed, 26 Mar 2003 19:45:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R0iUO18048 for ; Wed, 26 Mar 2003 19:44:30 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24579 for ; Wed, 26 Mar 2003 19:22:57 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2R0PHX28787 for ; Wed, 26 Mar 2003 19:25:18 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Mar 2003 01:25:16 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550137BC94@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Randy Presuhn , bwijnen@lucent.com Cc: "Randy Bush (E-mail)" , "Disman (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Disman] RE: Report of disman WG session at San Francisco IETF meeting Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Mar 2003 01:25:16 +0100 Thanks Bert From mailnull@www1.ietf.org Mon Mar 31 00:20:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13906 for ; Mon, 31 Mar 2003 00:20:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2V5hO926498 for disman-archive@odin.ietf.org; Mon, 31 Mar 2003 00:43:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V5hOO26495 for ; Mon, 31 Mar 2003 00:43:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13892 for ; Mon, 31 Mar 2003 00:19:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V5gcO26459; Mon, 31 Mar 2003 00:42:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V5avO25468 for ; Mon, 31 Mar 2003 00:36:57 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13747 for ; Mon, 31 Mar 2003 00:13:22 -0500 (EST) Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2V5Fjs15342 for ; Mon, 31 Mar 2003 00:15:46 -0500 (EST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Mar 2003 00:15:45 -0500 Message-ID: From: "Lam, Hing-Kam (Kam)" To: disman@ietf.org Cc: "Wijnen, Bert (Bert)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Disman] ARC MIB update Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Mar 2003 00:15:40 -0500 Hi, Per the Minutes of the Disman WG meeting in San Francisco on March 19th, 2003: > 6. Hing-Kam Lam needs to look at latest version of ID nits doc, the > update to the RFC authors > guidelines - for the ARC MIB update, as well as the latest guidelines > for MIB reviewers. > > 7. Kam to make known edits to ARC from above tasks, and send > it to Bert > and internet-drafts... > I have updated the ARC MIB to produce a version 07. I will send it to Bert and internet-drafts soon. The following is a summary of the updates. (a) Replace Section 2 by the New MIB boilerplate. (b) Because of the above change, replace Section 2 heading in the Table of Content; remove references to RFC1155, RFC1157, RFC1212, RFC1215, RFC1901, RFC1905, RFC1906, RFC2570, RFC2571, RFC2572, RFC2573, RFC2574, and RFC2575 (RFC2574 and RFC2575 are not needed in the new Security guidelines neither); add informative reference for RFC3410. add [RFC2119] to section 3 and add normative reference for RFC2119. (c) Revise Section 6 according to the New MIB security guidelines. (d) Update the year for the copyright statements. Update the date in the MIB module. Also in the DESCRIPTION clause of the MODULE-IDENTITY, replace DESCRIPTION "The MIB module describes the objects for controlling a resource in reporting alarm conditions that it detects." by DESCRIPTION "The MIB module describes the objects for controlling a resource in reporting alarm conditions that it detects. Copyright (C) The Internet Society (2003). This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." -- RFC Ed.: replace yyyy with actual RFC number & remove this note (e) Replace ::={ mib-2 yy } by ::={ mib-2 yy } -- to be assigned by IANA (f) Update format per ID-nits: Un-numbered Abstract section. Make first part of Old Section 3 as new Section 1 for Introduction. Make second part of old Section 3 as new Section 3 for Conventions. (g) Update according to the MIB Reviewer Guideline: Change the descriptor associated with the MODULE-IDENTIFY invocation from arcMIB to arcMibModule. Change the name of the descriptor arcMIBTITimeInterval to arcTITimeInterval. Change the name of the descriptor arcMIBCDTimeInterval to arcCDTimeInterval. (h) Remove the importing of Identifier `Unsigned32', which is never used Regards, Kam From mailnull@www1.ietf.org Mon Mar 31 12:37:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15889 for ; Mon, 31 Mar 2003 12:37:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VI1GI02278 for disman-archive@odin.ietf.org; Mon, 31 Mar 2003 13:01:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VI1FK02275 for ; Mon, 31 Mar 2003 13:01:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15819 for ; Mon, 31 Mar 2003 12:37:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VHs8K01893; Mon, 31 Mar 2003 12:54:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VHqAK01828 for ; Mon, 31 Mar 2003 12:52:10 -0500 Received: from flamingo.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15408 for ; Mon, 31 Mar 2003 12:28:19 -0500 (EST) Received: from h-68-164-72-88.snvacaid.covad.net ([68.164.72.88] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19037K-00053I-00 for disman@ietf.org; Mon, 31 Mar 2003 09:30:42 -0800 Message-ID: <004a01c2f7ab$6e9dd160$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Disman] ARC MIB update X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Mar 2003 09:31:57 -0800 Hi - > From: "Lam, Hing-Kam (Kam)" > To: > Cc: "Wijnen, Bert (Bert)" > Sent: Sunday, March 30, 2003 9:15 PM > Subject: [Disman] ARC MIB update ... > I have updated the ARC MIB to produce a version 07. I will send it to Bert and internet-drafts soon. ... Thanks, Kam! Randy