From mailman-admin@ietf.org Fri Aug 1 09:32:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14096 for ; Fri, 1 Aug 2003 09:18:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iZfB-0005fX-Gr for disman-archive@lists.ietf.org; Fri, 01 Aug 2003 09:09:41 -0400 Date: Fri, 01 Aug 2003 09:09:41 -0400 Message-ID: <20030801130941.29120.19125.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 exim@www1.ietf.org Fri Aug 1 14:01:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02561 for ; Fri, 1 Aug 2003 14:01:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ieD9-0005Rc-Dz for disman-archive@odin.ietf.org; Fri, 01 Aug 2003 14:01:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71I13Za020920 for disman-archive@odin.ietf.org; Fri, 1 Aug 2003 14:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iac6-0005Fl-7y for disman-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 10:10:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17070 for ; Fri, 1 Aug 2003 09:35:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iZxv-000051-00 for disman-web-archive@ietf.org; Fri, 01 Aug 2003 09:29:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iZma-0005pG-01 for disman-web-archive@ietf.org; Fri, 01 Aug 2003 09:17:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iZe1-0003RD-9z for disman-web-archive@ietf.org; Fri, 01 Aug 2003 09:08:29 -0400 Date: Fri, 01 Aug 2003 09:08:29 -0400 Message-ID: <20030801130829.29120.40785.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: disman-web-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-web-archive@ietf.org: List Password // URL ---- -------- disman@ietf.org carehu https://www1.ietf.org/mailman/options/disman/disman-web-archive%40ietf.org From disman-admin@ietf.org Thu Aug 7 02:20:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01801 for ; Thu, 7 Aug 2003 02:20:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ke82-0005nq-21; Thu, 07 Aug 2003 02:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ke7V-0005mD-2M for disman@optimus.ietf.org; Thu, 07 Aug 2003 02:19:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01690 for ; Thu, 7 Aug 2003 02:19:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ke7R-00038m-00 for disman@ietf.org; Thu, 07 Aug 2003 02:19:25 -0400 Received: from falcon.mail.pas.earthlink.net ([207.217.120.74]) by ietf-mx with esmtp (Exim 4.12) id 19ke7Q-00038i-00 for disman@ietf.org; Thu, 07 Aug 2003 02:19:24 -0400 Received: from h-68-164-17-204.snvacaid.covad.net ([68.164.17.204] helo=oemcomputer) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19ke7D-0002JC-00; Wed, 06 Aug 2003 23:19:11 -0700 Message-ID: <001f01c35cab$578801c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Sharon Chisholm" , "Romascanu, Dan \(Dan\)" Cc: , "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Comments on draft-ietf-disman-alarm-mib-14.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: Wed, 6 Aug 2003 23:15:46 -0700 Hi - Here's what I found in draft-ietf-disman-alarm-mib-14.txt I think most could be fixed as "editorial", except for #43, 46, 47, 51, 55, 59, 66, 68, 69, 71, and 75 which raise more interesting technical issues. Sorry this took so long. I'm having far too much fun not working. :-) 1) Page 1: "Avaya Inc" should probably be "Avaya Inc." since that's how the company refers to itself on its website. 2) the FF character is merged with the header lines, resulting in many too-long lines. The RFC editor can fix these. line 59 too long (73 characters) line 117 too long (73 characters) line 175 too long (73 characters) line 233 too long (73 characters) line 291 too long (73 characters) line 349 too long (73 characters) line 407 too long (73 characters) line 465 too long (73 characters) line 523 too long (73 characters) line 581 too long (73 characters) line 639 too long (73 characters) line 697 too long (73 characters) line 755 too long (73 characters) line 813 too long (73 characters) line 871 too long (73 characters) line 929 too long (73 characters) line 987 too long (73 characters) line 1045 too long (73 characters) line 1103 too long (73 characters) line 1161 too long (73 characters) line 1219 too long (73 characters) line 1277 too long (73 characters) line 1335 too long (73 characters) line 1393 too long (73 characters) line 1451 too long (73 characters) line 1509 too long (73 characters) line 1567 too long (73 characters) line 1625 too long (73 characters) line 1683 too long (73 characters) line 1741 too long (73 characters) line 1799 too long (73 characters) line 1857 too long (73 characters) line 1915 too long (73 characters) line 1973 too long (73 characters) line 2031 too long (73 characters) line 2089 too long (73 characters) line 2147 too long (73 characters) line 2205 too long (73 characters) line 2263 too long (73 characters) line 2321 too long (73 characters) line 2379 too long (73 characters) line 2437 too long (73 characters) line 2495 too long (73 characters) line 2553 too long (73 characters) line 2611 too long (73 characters) line 2669 too long (73 characters) line 2727 too long (73 characters) line 2785 too long (73 characters) line 2843 too long (73 characters) line 2901 too long (73 characters) line 2959 too long (73 characters) line 3017 too long (73 characters) line 3075 too long (73 characters) line 3133 too long (73 characters) line 3191 too long (73 characters) line 3249 too long (73 characters) line 3307 too long (73 characters) line 3365 too long (73 characters) line 3423 too long (73 characters) line 3481 too long (73 characters) line 3539 too long (73 characters) line 3597 too long (73 characters) line 3655 too long (73 characters) line 3713 too long (73 characters) line 3771 too long (73 characters) 3) Page 3: "monitoring large number of entities" -> "monitoring large numbers of entities" 4) Page 3: "high-reliability" -> "high reliability" 5) Page 3: "accurately determine problems that may have occurred when" -> "accurately identifiy problems that may have occurred while" or "accurately determine whether problems have occurred while" 6) Page 3: "on the entity and even after" -> "on the entity. Even after" 7) Page 3: "be able to determine current problems on a system" -> "be able to determine what the current problems on a system are" 8) Page 3: "This memo describes a method of using alarm management in SNMP to address these problems. It also provides the necessary MIB objects to support these methods." change "a method" to "methods" or change "these methods" to "this method". 9) Page 3: "alarms management" -> "alarm management" 10) Page 4: "of interest to a management station" -> "of interest". (one does not need a management station for events to be meaningful and useful, particularly in a disman context.) 11) Page 4: "transmissions of management" -> "transmission of management" (I personally think that defining "notification" in terms of transmission is a mistake, but it's too late to re-hash that discussion.) 12) Page 4: "ITU" acronym should be expanded, for "ITU model" a reference should be given. 13) Page 4: formatting of "Alarm State" paragraph is odd; there is a premature line break after "also". 14) Page 4: "A notification SHOULD be sent on alarm raise." Given the definition of notification, and the role of RFC 3413, this sentence should be deleted. Whether a notification should be sent depends on whether some manager is interested in it and has configured the SNMP-NOTIFICATION-MIB and SNMP-TARGET-MIB accordingly. 15a) (global) The document is inconsistent in its use of space after period at the end of a sentence. There should consistently be two spaces after each period ending a sentence. 15b) Page 4: "A notification SHOULD be sent on alarm clear." Delete this sentence, same rationale as (14) above. 16) (global) "modelling" -> "modeling", "modelled" -> "modeled" "behaviour" -> "behavior" A spelling check would be advisable to extirpate the briticisms. 17) Page 6: "OID" acronym should be expanded 18) Page 6: "offset, value pair" -> "(offset, value) pair" 19) Section 3.3.2, third paragraph, first sentence: "identify" -> "specify", and "define" -> "identify" 20) Section 3.3.2, third paragraph: the phrase "when the entity generated a Notification" isn't right, given the way "notification" is defined. However, if it doesn't confuse anyone, I guess we can leave it the way it is. 21) Page 6: "Notifications, use" -> "Notifications use" 22) Page 6: "These alarm states would be entered by some internal stimuli" This is literally wrong. "entered" -> "triggered" would make much more sense. 22) Page 6: both occurrances of "indicated in the SNMP-TARGET-MIB" should be amended to include "SNMP-NOTIFICATION-MIB". Otherwise it's just plain wrong. 23) Page 6: "by some internal stimuli" -> "by some internal stimulus" (though it would probably be more correct to say "by some stimulus outside the scope of this memo") 24) Section 3.3.3: the first sentence is a bit hard to swallow: as a practical matter, to find out which notifications are not of interest, one would have to walk the alarm model table to find out what *is* of interest, and then remove that set from the set of all possible notifications, which isn't listed in any convenient spot. 25) (global) be consistent: "ITU Alarm MIB" or "ITU-ALARM-MIB". 26) Section 3.3.5: "Solutions interested in being able to differentiate the source of the alarm by means other than the source IP address and resource ID" is at odds with what's actually done in the alarmActiveEntry and alarmClearEntry. Both include information for the LocalSnmpEngineOrZeroLenStr, AddressType, EngineAddress, and ContextName. 27) Section 3.7 "Notification log MIB" -> Notification Log MIB" (and elsewhere) 29) withdrawn 28) Section 3.7: "This format allows for the storage of any Trap or Notification that can be defined using SMIv1 or SMIv2." Not quite consistent with definition of "Notification"; suggest "instance of any TRAP-TYPE or NOTIFICATION-TYPE", though I think talking about SMIv1 and SMIv2 isn't helpful here. See #47 below. 29) Page 10: "other state transition relationship between" -> "other state transition relationships between" 30) Page 10: "alarmModelIndex acts as a unique" -> "The alarmModelIndex acts as a unique" 31) Page 10: "consists of defining the" -> "consists of definitions of the" 32) Page 10: "that is sent out when an alarm changes state" The notification may be generated, but whether it is actually sent out (on the wire) is another matter. For example, it might be logged locally but *not* forwarded to a management station. 33) Section 4.1.1: one consequence of this approach is that one cannot use multiple extensions for a single alarm. So, for example, one couldn't make an extension to the ITU Alarm MIB and have it work using the method described here. This may be the intent, but it would be good to be explicit about it. 34) Section 4.1.2: alarmModelDescription might get some grief from internationalization experts (see RFC 2130), but this was hashed out in the WG. 35) Section 4.1.3: (see comment 14 above) this paragraph doesn't tell the whole story of what a manager needs to do to get these notifications. The sentence beginning with "alternatively" only makes things worse, since it will result in a configuration that is contrary to the goal in the paragraph's topic sentence. 36) Page 11: "interface for example" -> "interface, for example" 37) page 12: "interested in resource type" -> "interested in a resource type" 38) Page 12 (A) (and (B, C) on page 13) should include references for these (copied) notification type definitions. 39) 4.1.5: "table can, and probably should, be" -> "table MAY be". I don't think we had consensus to make this a SHOULD, but I'm open to the possibility. 40) 4.1.5: "the manager" -> "managers" 41) 4.1.6: "and, optionally" -> "and, optionally," 42) 4.1.7: "therefore," -> "" 43) page 15 (ResourceId): I agree with the intent of the last sentence in the description, but if there is a MUST requirement here, how do we ensure that implementations know what to choose for any arbitrary table? 44) page 15 (LocalSnmpEngineOrZeroLenStr): where the DESCRIPTION talks about "instantiation" doesn't make sense. I think it's referring to use of the TC in an OBJECT-TYPE definition, rather than object instantiation. 45) page 16: "zero lengths string" -> "zero-length string" 46) page 16 (alarmModelLastChanged) I think this would be more robust if it were a persistent DateAndTime rather than TimeTicks, using the "0000...." convention for virginal value, particularly given the persistence requirements of the table. 47) (alarmModelVarbindIndex) (also alarmActiveVariableEntry) I repeat my comments from May, since they're still not reflected in the draft: > The words that are there now seem to be backwards from what I thought > was agreed: since RFC 3416 is Standard, and 1157 is Historic, that the > numbering should start with 1 for the SysUptime, which would be the value > extracted from elsewhere in the PDU in the case of a SNMPv1 trap. What's > there now (still) seems unnecessarily confusing. > > Note that Harrie Hazewinkel's message of March 18, 2003 also has concerns > with this same paragraph. > > The discussion back in April 22, 2002 went the same way, and Sharon's post > of June 3, 2002 gave the resolution of issue #38 as being to treat everything > "v2-style". 48) alarmModelNotificationId should have a DEFVAL of { 0 0 } 49) alarmModelRowStatus should spell out that the alarmModelVarbindIndex and alarmModelVarbindValue MUST be set before row can go active. 50) alarmModelDescription should have a DEFVAL of "" 51) alarmModelSpecificPointer should have a DEFVAL of { 0 0 } DESCRIPTION should specify what it means of the referenced row does not exist. 52) alarmModelVarbindSubtree should have a DEFVAL of { 0 0 } 53) alarmModelResourcePrefix should have a DEFVAL of { 0 0 } 54) page 19: "RFC2579" -> "RFC2579." 55) alarmModelRowStatus does not permit modification of a model while active alarms exist. This would seem to create the possibility of "un-throttle-able" alarm storms, contrary to the spirit of draft-ietf-ops-mib-review-guidelines-01.txt section 4.7 last paragraph. 56) alarmListName's DESCRIPTION should spell how this object's value hooks into the SNMP-NOTIFICATION-MIB. Without out this bit of explanation, the whole thing is magic. 57) alarmActiveEngineID: the phrase "alarms from only one engine" isn't quite what I though we meant to accomplish. Wouldn't "only local alarms" be more to the point? Same goes for alarmClearEngineID 58) alarmActiveEngineAddress: "IP Address" -> "address" ditto alarmClearEngineAddress 59) alarmActiveContextName: this is defined to be an SnmpAdminString. This is fine for the case where its value is a context name. However, in the case where it is a community, provision needs to be made for the possibility that the community name would not be a well-formed SnmpAdminString. (for example, 0xFF would be a legal community, but would violate the rules for UTF-8.) ditto alarmClearContextName 60) alarmActiveLogPointer: should spell out that the log's name would be the same as alarmListName for this instance. ditto alarmClearLogIndex 61) page 25: "is used" -> "is used for a given row in this table" 62) alarmActiveStatsActives, the SYNTAX says this is a Counter32, but the DESCRIPTION sure makes it sound like it's supposed to be zero-based. 63) alarmActiveState, alarmClearState: the names for these notifications aren't terribly good. more importantly, something needs to be said about throttling per draft-ietf-ops-mib-review-guidelines-01.txt section 4.7 last paragraph, perhaps simply to the effect that these are "second order" notifications that rely on lower-level throttling and filter specification. 64) alarmCompliance: is having so many unconditionally optional groups a good idea, particularly in light of RFC 2026 section 4.1.2 paragraph two? 65) 5.1: "about alarms" -> "about alarms modeled using the ituAlarmTable" "total alarms" -> "total alarms modeled using the ituAlarmTable" 66) 5.2: we will probably need to give IANA more guidance on how additions should be approved. We agreed that we didn't want an immortal WG, but we do need to tell them what kind of review, if any, is needed before a addition is made. 67) Page 45: '" Represents' -> '"Represents' 68) ituAlarmGenericModel: why is this object needed? the indexing information needed to find the model entry is the same for both tables. 69) ituAlarmEntry: the DESCRIPTION needs to say something about how rows in this table come into existence. Currently, it looks like immaculate conception. If these things are created under management control, then I'd strongly suggest DEFVALs for ituAlarmPerceivedSeverity, ituAlarmEventType, ituAlarmProbableCause, and ituAlarmAdditionalText. The table should probably say something about persistence as well. 70) ituAlarmActiveDetector, ituAlarmActiveServiceProvider, and ituAlarmActiveServiceUser need better DESCRIPTIONs. I think it needs to be more explicit that their values are the names of the object instances corresponding to these resources. 71) ituAlarmActiveStatsIndeterminates, ituAlarmActiveStatsCriticals, ituAlarmActiveStatsMajors, ituAlarmActiveStatsMinors, and ituAlarmActiveStatsWarnings are all Counter32, but their DESCRIPTIONs sound like they're assumed to be zero-based. 72) The DESCRIPTION of ituAlarmServiceUserGroup isn't helpful. 73) ituAlarmCompliance: see comment #64. 74) section 6.1 should have a reference for the notification type definitions 75) Section 7 should describe the need for security administrators to configure a coherent VACM policy for the configuration of the SNMP-NOTIFICATION-MIB, the log MIB, and these MIBs based on log name. This section should also mention throttling / DoS attacks based on notification generation. It should also note that alarm clearing (alarmClearMaximum) could cause retained security alarm information (for example) to be lost. I missed anything like an "alarmActiveMaximum", yet the document doesn't seem to describe what should happen if there are too many active alarms, as might happen if there are lots of instances of a particular type of resource, and an admimistrator inadvertantly specifies a frequent, innoccuous event as being of interest. Randy From exim@www1.ietf.org Thu Aug 7 02:20:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01816 for ; Thu, 7 Aug 2003 02:20:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ke8C-0005p0-Bl for disman-archive@odin.ietf.org; Thu, 07 Aug 2003 02:20:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h776KCtW022377 for disman-archive@odin.ietf.org; Thu, 7 Aug 2003 02:20:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ke8B-0005oq-TU for disman-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 02:20:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01755 for ; Thu, 7 Aug 2003 02:20:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ke88-000396-00 for disman-web-archive@ietf.org; Thu, 07 Aug 2003 02:20:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ke87-000392-00 for disman-web-archive@ietf.org; Thu, 07 Aug 2003 02:20:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ke82-0005nq-21; Thu, 07 Aug 2003 02:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ke7V-0005mD-2M for disman@optimus.ietf.org; Thu, 07 Aug 2003 02:19:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01690 for ; Thu, 7 Aug 2003 02:19:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ke7R-00038m-00 for disman@ietf.org; Thu, 07 Aug 2003 02:19:25 -0400 Received: from falcon.mail.pas.earthlink.net ([207.217.120.74]) by ietf-mx with esmtp (Exim 4.12) id 19ke7Q-00038i-00 for disman@ietf.org; Thu, 07 Aug 2003 02:19:24 -0400 Received: from h-68-164-17-204.snvacaid.covad.net ([68.164.17.204] helo=oemcomputer) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19ke7D-0002JC-00; Wed, 06 Aug 2003 23:19:11 -0700 Message-ID: <001f01c35cab$578801c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Sharon Chisholm" , "Romascanu, Dan \(Dan\)" Cc: , "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Comments on draft-ietf-disman-alarm-mib-14.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: Wed, 6 Aug 2003 23:15:46 -0700 Hi - Here's what I found in draft-ietf-disman-alarm-mib-14.txt I think most could be fixed as "editorial", except for #43, 46, 47, 51, 55, 59, 66, 68, 69, 71, and 75 which raise more interesting technical issues. Sorry this took so long. I'm having far too much fun not working. :-) 1) Page 1: "Avaya Inc" should probably be "Avaya Inc." since that's how the company refers to itself on its website. 2) the FF character is merged with the header lines, resulting in many too-long lines. The RFC editor can fix these. line 59 too long (73 characters) line 117 too long (73 characters) line 175 too long (73 characters) line 233 too long (73 characters) line 291 too long (73 characters) line 349 too long (73 characters) line 407 too long (73 characters) line 465 too long (73 characters) line 523 too long (73 characters) line 581 too long (73 characters) line 639 too long (73 characters) line 697 too long (73 characters) line 755 too long (73 characters) line 813 too long (73 characters) line 871 too long (73 characters) line 929 too long (73 characters) line 987 too long (73 characters) line 1045 too long (73 characters) line 1103 too long (73 characters) line 1161 too long (73 characters) line 1219 too long (73 characters) line 1277 too long (73 characters) line 1335 too long (73 characters) line 1393 too long (73 characters) line 1451 too long (73 characters) line 1509 too long (73 characters) line 1567 too long (73 characters) line 1625 too long (73 characters) line 1683 too long (73 characters) line 1741 too long (73 characters) line 1799 too long (73 characters) line 1857 too long (73 characters) line 1915 too long (73 characters) line 1973 too long (73 characters) line 2031 too long (73 characters) line 2089 too long (73 characters) line 2147 too long (73 characters) line 2205 too long (73 characters) line 2263 too long (73 characters) line 2321 too long (73 characters) line 2379 too long (73 characters) line 2437 too long (73 characters) line 2495 too long (73 characters) line 2553 too long (73 characters) line 2611 too long (73 characters) line 2669 too long (73 characters) line 2727 too long (73 characters) line 2785 too long (73 characters) line 2843 too long (73 characters) line 2901 too long (73 characters) line 2959 too long (73 characters) line 3017 too long (73 characters) line 3075 too long (73 characters) line 3133 too long (73 characters) line 3191 too long (73 characters) line 3249 too long (73 characters) line 3307 too long (73 characters) line 3365 too long (73 characters) line 3423 too long (73 characters) line 3481 too long (73 characters) line 3539 too long (73 characters) line 3597 too long (73 characters) line 3655 too long (73 characters) line 3713 too long (73 characters) line 3771 too long (73 characters) 3) Page 3: "monitoring large number of entities" -> "monitoring large numbers of entities" 4) Page 3: "high-reliability" -> "high reliability" 5) Page 3: "accurately determine problems that may have occurred when" -> "accurately identifiy problems that may have occurred while" or "accurately determine whether problems have occurred while" 6) Page 3: "on the entity and even after" -> "on the entity. Even after" 7) Page 3: "be able to determine current problems on a system" -> "be able to determine what the current problems on a system are" 8) Page 3: "This memo describes a method of using alarm management in SNMP to address these problems. It also provides the necessary MIB objects to support these methods." change "a method" to "methods" or change "these methods" to "this method". 9) Page 3: "alarms management" -> "alarm management" 10) Page 4: "of interest to a management station" -> "of interest". (one does not need a management station for events to be meaningful and useful, particularly in a disman context.) 11) Page 4: "transmissions of management" -> "transmission of management" (I personally think that defining "notification" in terms of transmission is a mistake, but it's too late to re-hash that discussion.) 12) Page 4: "ITU" acronym should be expanded, for "ITU model" a reference should be given. 13) Page 4: formatting of "Alarm State" paragraph is odd; there is a premature line break after "also". 14) Page 4: "A notification SHOULD be sent on alarm raise." Given the definition of notification, and the role of RFC 3413, this sentence should be deleted. Whether a notification should be sent depends on whether some manager is interested in it and has configured the SNMP-NOTIFICATION-MIB and SNMP-TARGET-MIB accordingly. 15a) (global) The document is inconsistent in its use of space after period at the end of a sentence. There should consistently be two spaces after each period ending a sentence. 15b) Page 4: "A notification SHOULD be sent on alarm clear." Delete this sentence, same rationale as (14) above. 16) (global) "modelling" -> "modeling", "modelled" -> "modeled" "behaviour" -> "behavior" A spelling check would be advisable to extirpate the briticisms. 17) Page 6: "OID" acronym should be expanded 18) Page 6: "offset, value pair" -> "(offset, value) pair" 19) Section 3.3.2, third paragraph, first sentence: "identify" -> "specify", and "define" -> "identify" 20) Section 3.3.2, third paragraph: the phrase "when the entity generated a Notification" isn't right, given the way "notification" is defined. However, if it doesn't confuse anyone, I guess we can leave it the way it is. 21) Page 6: "Notifications, use" -> "Notifications use" 22) Page 6: "These alarm states would be entered by some internal stimuli" This is literally wrong. "entered" -> "triggered" would make much more sense. 22) Page 6: both occurrances of "indicated in the SNMP-TARGET-MIB" should be amended to include "SNMP-NOTIFICATION-MIB". Otherwise it's just plain wrong. 23) Page 6: "by some internal stimuli" -> "by some internal stimulus" (though it would probably be more correct to say "by some stimulus outside the scope of this memo") 24) Section 3.3.3: the first sentence is a bit hard to swallow: as a practical matter, to find out which notifications are not of interest, one would have to walk the alarm model table to find out what *is* of interest, and then remove that set from the set of all possible notifications, which isn't listed in any convenient spot. 25) (global) be consistent: "ITU Alarm MIB" or "ITU-ALARM-MIB". 26) Section 3.3.5: "Solutions interested in being able to differentiate the source of the alarm by means other than the source IP address and resource ID" is at odds with what's actually done in the alarmActiveEntry and alarmClearEntry. Both include information for the LocalSnmpEngineOrZeroLenStr, AddressType, EngineAddress, and ContextName. 27) Section 3.7 "Notification log MIB" -> Notification Log MIB" (and elsewhere) 29) withdrawn 28) Section 3.7: "This format allows for the storage of any Trap or Notification that can be defined using SMIv1 or SMIv2." Not quite consistent with definition of "Notification"; suggest "instance of any TRAP-TYPE or NOTIFICATION-TYPE", though I think talking about SMIv1 and SMIv2 isn't helpful here. See #47 below. 29) Page 10: "other state transition relationship between" -> "other state transition relationships between" 30) Page 10: "alarmModelIndex acts as a unique" -> "The alarmModelIndex acts as a unique" 31) Page 10: "consists of defining the" -> "consists of definitions of the" 32) Page 10: "that is sent out when an alarm changes state" The notification may be generated, but whether it is actually sent out (on the wire) is another matter. For example, it might be logged locally but *not* forwarded to a management station. 33) Section 4.1.1: one consequence of this approach is that one cannot use multiple extensions for a single alarm. So, for example, one couldn't make an extension to the ITU Alarm MIB and have it work using the method described here. This may be the intent, but it would be good to be explicit about it. 34) Section 4.1.2: alarmModelDescription might get some grief from internationalization experts (see RFC 2130), but this was hashed out in the WG. 35) Section 4.1.3: (see comment 14 above) this paragraph doesn't tell the whole story of what a manager needs to do to get these notifications. The sentence beginning with "alternatively" only makes things worse, since it will result in a configuration that is contrary to the goal in the paragraph's topic sentence. 36) Page 11: "interface for example" -> "interface, for example" 37) page 12: "interested in resource type" -> "interested in a resource type" 38) Page 12 (A) (and (B, C) on page 13) should include references for these (copied) notification type definitions. 39) 4.1.5: "table can, and probably should, be" -> "table MAY be". I don't think we had consensus to make this a SHOULD, but I'm open to the possibility. 40) 4.1.5: "the manager" -> "managers" 41) 4.1.6: "and, optionally" -> "and, optionally," 42) 4.1.7: "therefore," -> "" 43) page 15 (ResourceId): I agree with the intent of the last sentence in the description, but if there is a MUST requirement here, how do we ensure that implementations know what to choose for any arbitrary table? 44) page 15 (LocalSnmpEngineOrZeroLenStr): where the DESCRIPTION talks about "instantiation" doesn't make sense. I think it's referring to use of the TC in an OBJECT-TYPE definition, rather than object instantiation. 45) page 16: "zero lengths string" -> "zero-length string" 46) page 16 (alarmModelLastChanged) I think this would be more robust if it were a persistent DateAndTime rather than TimeTicks, using the "0000...." convention for virginal value, particularly given the persistence requirements of the table. 47) (alarmModelVarbindIndex) (also alarmActiveVariableEntry) I repeat my comments from May, since they're still not reflected in the draft: > The words that are there now seem to be backwards from what I thought > was agreed: since RFC 3416 is Standard, and 1157 is Historic, that the > numbering should start with 1 for the SysUptime, which would be the value > extracted from elsewhere in the PDU in the case of a SNMPv1 trap. What's > there now (still) seems unnecessarily confusing. > > Note that Harrie Hazewinkel's message of March 18, 2003 also has concerns > with this same paragraph. > > The discussion back in April 22, 2002 went the same way, and Sharon's post > of June 3, 2002 gave the resolution of issue #38 as being to treat everything > "v2-style". 48) alarmModelNotificationId should have a DEFVAL of { 0 0 } 49) alarmModelRowStatus should spell out that the alarmModelVarbindIndex and alarmModelVarbindValue MUST be set before row can go active. 50) alarmModelDescription should have a DEFVAL of "" 51) alarmModelSpecificPointer should have a DEFVAL of { 0 0 } DESCRIPTION should specify what it means of the referenced row does not exist. 52) alarmModelVarbindSubtree should have a DEFVAL of { 0 0 } 53) alarmModelResourcePrefix should have a DEFVAL of { 0 0 } 54) page 19: "RFC2579" -> "RFC2579." 55) alarmModelRowStatus does not permit modification of a model while active alarms exist. This would seem to create the possibility of "un-throttle-able" alarm storms, contrary to the spirit of draft-ietf-ops-mib-review-guidelines-01.txt section 4.7 last paragraph. 56) alarmListName's DESCRIPTION should spell how this object's value hooks into the SNMP-NOTIFICATION-MIB. Without out this bit of explanation, the whole thing is magic. 57) alarmActiveEngineID: the phrase "alarms from only one engine" isn't quite what I though we meant to accomplish. Wouldn't "only local alarms" be more to the point? Same goes for alarmClearEngineID 58) alarmActiveEngineAddress: "IP Address" -> "address" ditto alarmClearEngineAddress 59) alarmActiveContextName: this is defined to be an SnmpAdminString. This is fine for the case where its value is a context name. However, in the case where it is a community, provision needs to be made for the possibility that the community name would not be a well-formed SnmpAdminString. (for example, 0xFF would be a legal community, but would violate the rules for UTF-8.) ditto alarmClearContextName 60) alarmActiveLogPointer: should spell out that the log's name would be the same as alarmListName for this instance. ditto alarmClearLogIndex 61) page 25: "is used" -> "is used for a given row in this table" 62) alarmActiveStatsActives, the SYNTAX says this is a Counter32, but the DESCRIPTION sure makes it sound like it's supposed to be zero-based. 63) alarmActiveState, alarmClearState: the names for these notifications aren't terribly good. more importantly, something needs to be said about throttling per draft-ietf-ops-mib-review-guidelines-01.txt section 4.7 last paragraph, perhaps simply to the effect that these are "second order" notifications that rely on lower-level throttling and filter specification. 64) alarmCompliance: is having so many unconditionally optional groups a good idea, particularly in light of RFC 2026 section 4.1.2 paragraph two? 65) 5.1: "about alarms" -> "about alarms modeled using the ituAlarmTable" "total alarms" -> "total alarms modeled using the ituAlarmTable" 66) 5.2: we will probably need to give IANA more guidance on how additions should be approved. We agreed that we didn't want an immortal WG, but we do need to tell them what kind of review, if any, is needed before a addition is made. 67) Page 45: '" Represents' -> '"Represents' 68) ituAlarmGenericModel: why is this object needed? the indexing information needed to find the model entry is the same for both tables. 69) ituAlarmEntry: the DESCRIPTION needs to say something about how rows in this table come into existence. Currently, it looks like immaculate conception. If these things are created under management control, then I'd strongly suggest DEFVALs for ituAlarmPerceivedSeverity, ituAlarmEventType, ituAlarmProbableCause, and ituAlarmAdditionalText. The table should probably say something about persistence as well. 70) ituAlarmActiveDetector, ituAlarmActiveServiceProvider, and ituAlarmActiveServiceUser need better DESCRIPTIONs. I think it needs to be more explicit that their values are the names of the object instances corresponding to these resources. 71) ituAlarmActiveStatsIndeterminates, ituAlarmActiveStatsCriticals, ituAlarmActiveStatsMajors, ituAlarmActiveStatsMinors, and ituAlarmActiveStatsWarnings are all Counter32, but their DESCRIPTIONs sound like they're assumed to be zero-based. 72) The DESCRIPTION of ituAlarmServiceUserGroup isn't helpful. 73) ituAlarmCompliance: see comment #64. 74) section 6.1 should have a reference for the notification type definitions 75) Section 7 should describe the need for security administrators to configure a coherent VACM policy for the configuration of the SNMP-NOTIFICATION-MIB, the log MIB, and these MIBs based on log name. This section should also mention throttling / DoS attacks based on notification generation. It should also note that alarm clearing (alarmClearMaximum) could cause retained security alarm information (for example) to be lost. I missed anything like an "alarmActiveMaximum", yet the document doesn't seem to describe what should happen if there are too many active alarms, as might happen if there are lots of instances of a particular type of resource, and an admimistrator inadvertantly specifies a frequent, innoccuous event as being of interest. Randy From disman-admin@ietf.org Sun Aug 17 16:06:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19923 for ; Sun, 17 Aug 2003 16:06:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oTlt-0002WP-Nn; Sun, 17 Aug 2003 16:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oTlY-0002W3-Dh for disman@optimus.ietf.org; Sun, 17 Aug 2003 16:04:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19850; Sun, 17 Aug 2003 16:04:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oTlW-0002T6-00; Sun, 17 Aug 2003 16:04:38 -0400 Received: from gull.mail.pas.earthlink.net ([207.217.120.84]) by ietf-mx with esmtp (Exim 4.12) id 19oTlW-0002T3-00; Sun, 17 Aug 2003 16:04:38 -0400 Received: from h-68-165-66-234.snvacaid.covad.net ([68.165.66.234] helo=oemcomputer) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19oTku-000265-00; Sun, 17 Aug 2003 13:04:00 -0700 Message-ID: <00d501c364fa$c264e6a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: , , , Cc: "Disman \(E-mail\)" , X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Ping capability in draft-ietf-ipcdn-cable-gateway-tools-mib-00.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: Sun, 17 Aug 2003 13:03:38 -0700 Hi - Glancing through draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt, I'm left wondering why it didn't just reference RFC 2925 for the ping capability. Since an update to RFC 2925 is in the works (draft-ietf-disman-remops-mib-v2-00.txt), are there any specific changes that we might make that would make the duplication unnecessary? Randy Presuhn (disman WG chair) > From: > To: > Cc: > Sent: Wednesday, June 25, 2003 7:54 AM > Subject: I-D ACTION:draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP over Cable Data Network Working Group of the IETF. > > Title : Cable Gateway Tools Management Information Base for > CableHome compliant Residential Gateways > Author(s) : E. Cardona et al. > Filename : draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt > Pages : 20 > Date : 2003-6-24 > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it defines a basic set of managed objects for SNMP- > based management of CableHome compliant WAN Gateway Devices and home > routers. Specifically, this MIB defines managed objects for both a > connection speed tool and an ICMP 'ping' tool between the Gateway and > devices on the LAN. > This memo specifies a MIB module in a manner that is compliant to the > SNMP SMIv2 [5][6][7]. The set of objects is consistent with the SNMP > framework and existing SNMP standards. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From exim@www1.ietf.org Sun Aug 17 16:06:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19938 for ; Sun, 17 Aug 2003 16:06:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oTmo-0002aW-Jr for disman-archive@odin.ietf.org; Sun, 17 Aug 2003 16:06:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7HK5wQ3009947 for disman-archive@odin.ietf.org; Sun, 17 Aug 2003 16:05:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oTmo-0002aM-G0 for disman-web-archive@optimus.ietf.org; Sun, 17 Aug 2003 16:05:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19876 for ; Sun, 17 Aug 2003 16:05:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oTmm-0002Tn-00 for disman-web-archive@ietf.org; Sun, 17 Aug 2003 16:05:56 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19oTmm-0002Tj-00 for disman-web-archive@ietf.org; Sun, 17 Aug 2003 16:05:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oTlt-0002WP-Nn; Sun, 17 Aug 2003 16:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oTlY-0002W3-Dh for disman@optimus.ietf.org; Sun, 17 Aug 2003 16:04:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19850; Sun, 17 Aug 2003 16:04:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oTlW-0002T6-00; Sun, 17 Aug 2003 16:04:38 -0400 Received: from gull.mail.pas.earthlink.net ([207.217.120.84]) by ietf-mx with esmtp (Exim 4.12) id 19oTlW-0002T3-00; Sun, 17 Aug 2003 16:04:38 -0400 Received: from h-68-165-66-234.snvacaid.covad.net ([68.165.66.234] helo=oemcomputer) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19oTku-000265-00; Sun, 17 Aug 2003 13:04:00 -0700 Message-ID: <00d501c364fa$c264e6a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: , , , Cc: "Disman \(E-mail\)" , X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Ping capability in draft-ietf-ipcdn-cable-gateway-tools-mib-00.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: Sun, 17 Aug 2003 13:03:38 -0700 Hi - Glancing through draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt, I'm left wondering why it didn't just reference RFC 2925 for the ping capability. Since an update to RFC 2925 is in the works (draft-ietf-disman-remops-mib-v2-00.txt), are there any specific changes that we might make that would make the duplication unnecessary? Randy Presuhn (disman WG chair) > From: > To: > Cc: > Sent: Wednesday, June 25, 2003 7:54 AM > Subject: I-D ACTION:draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP over Cable Data Network Working Group of the IETF. > > Title : Cable Gateway Tools Management Information Base for > CableHome compliant Residential Gateways > Author(s) : E. Cardona et al. > Filename : draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt > Pages : 20 > Date : 2003-6-24 > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it defines a basic set of managed objects for SNMP- > based management of CableHome compliant WAN Gateway Devices and home > routers. Specifically, this MIB defines managed objects for both a > connection speed tool and an ICMP 'ping' tool between the Gateway and > devices on the LAN. > This memo specifies a MIB module in a manner that is compliant to the > SNMP SMIv2 [5][6][7]. The set of objects is consistent with the SNMP > framework and existing SNMP standards. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From disman-admin@ietf.org Fri Aug 22 01:35:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22362 for ; Fri, 22 Aug 2003 01:35:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q4Zj-0005H5-8M; Fri, 22 Aug 2003 01:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q4Z9-0005F5-M9 for disman@optimus.ietf.org; Fri, 22 Aug 2003 01:34:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22290 for ; Fri, 22 Aug 2003 01:34:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q4Z6-0006vq-00 for disman@ietf.org; Fri, 22 Aug 2003 01:34:24 -0400 Received: from snipe.mail.pas.earthlink.net ([207.217.120.62]) by ietf-mx with esmtp (Exim 4.12) id 19q4Z5-0006vm-00 for disman@ietf.org; Fri, 22 Aug 2003 01:34:24 -0400 Received: from h-68-164-29-153.snvacaid.covad.net ([68.164.29.153] helo=oemcomputer) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19q4Yz-0007Gb-00 for disman@ietf.org; Thu, 21 Aug 2003 22:34:17 -0700 Message-ID: <001f01c3686f$1e1a3b40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] brazilian spam 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, 21 Aug 2003 22:34:54 -0700 Hi - > From: "Na contram?o! -" > To: > Sent: Thursday, August 21, 2003 3:21 PM > Subject: Reforma Agrária: absoluto fracasso, afirma jornalista The spam filters should have caught this. It's not from a list member, and there were several bits in the headers that should have caused it to be held for approval. If you know how this trash got through, I'd appreciate a clue. Randy From exim@www1.ietf.org Fri Aug 22 01:35:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22378 for ; Fri, 22 Aug 2003 01:35:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q4Zq-0005IT-Jp for disman-archive@odin.ietf.org; Fri, 22 Aug 2003 01:35:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7M5ZAwA020357 for disman-archive@odin.ietf.org; Fri, 22 Aug 2003 01:35:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q4Zq-0005IG-Ft for disman-web-archive@optimus.ietf.org; Fri, 22 Aug 2003 01:35:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22318 for ; Fri, 22 Aug 2003 01:35:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q4Zn-0006wR-00 for disman-web-archive@ietf.org; Fri, 22 Aug 2003 01:35:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19q4Zm-0006wO-00 for disman-web-archive@ietf.org; Fri, 22 Aug 2003 01:35:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q4Zj-0005H5-8M; Fri, 22 Aug 2003 01:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q4Z9-0005F5-M9 for disman@optimus.ietf.org; Fri, 22 Aug 2003 01:34:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22290 for ; Fri, 22 Aug 2003 01:34:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q4Z6-0006vq-00 for disman@ietf.org; Fri, 22 Aug 2003 01:34:24 -0400 Received: from snipe.mail.pas.earthlink.net ([207.217.120.62]) by ietf-mx with esmtp (Exim 4.12) id 19q4Z5-0006vm-00 for disman@ietf.org; Fri, 22 Aug 2003 01:34:24 -0400 Received: from h-68-164-29-153.snvacaid.covad.net ([68.164.29.153] helo=oemcomputer) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19q4Yz-0007Gb-00 for disman@ietf.org; Thu, 21 Aug 2003 22:34:17 -0700 Message-ID: <001f01c3686f$1e1a3b40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] brazilian spam 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, 21 Aug 2003 22:34:54 -0700 Hi - > From: "Na contram?o! -" > To: > Sent: Thursday, August 21, 2003 3:21 PM > Subject: Reforma Agrária: absoluto fracasso, afirma jornalista The spam filters should have caught this. It's not from a list member, and there were several bits in the headers that should have caused it to be held for approval. If you know how this trash got through, I'd appreciate a clue. Randy