http://permalink.gmane.org/gmane.ietf.disman hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.disman/1304 <pre>Hi - Forwarded for your information, and, hopefully, action. Randy ----- Original Message ----- From: "NomCom Chair" &lt;nomcom-chair&lt; at &gt;ietf.org&gt; To: "Working Group Chairs" &lt;wgchairs&lt; at &gt;ietf.org&gt; Sent: Thursday, November 01, 2012 5:17 AM Subject: CORRECTION: Help the NomCom I sent a message several hours ago requesting that you help and make your working group aware that the NomCom is looking for input from the community. This message had a minor error. The NomCom needs to receive community input by November 11, 2012. The full text of the corrected message is below --------------------------------------------------- The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the NomCom needs to receive community feedback on or before</pre> Randy Presuhn 2012-11-01T18:46:51 http://permalink.gmane.org/gmane.ietf.disman/1303 <pre>Hi - Now, as then, I see no great need for aligning the values, as long as there is an obvious mapping between them. I agree that the IANA mechanism seems like the right way to go. Randy ----- Original Message ----- From: "Romascanu, Dan (Dan)" &lt;dromasca&lt; at &gt;avaya.com&gt; To: "Randy Presuhn" &lt;randy_presuhn&lt; at &gt;mindspring.com&gt;; "April Pennisi" &lt;april.pennisi&lt; at &gt;genband.com&gt; Cc: &lt;disman&lt; at &gt;ietf.org&gt; Sent: Monday, April 23, 2012 10:40 AM Subject: RE: [Disman] Alarm Mib Well, yes, the resolution proposed to the errata was correct if we are to align the values of the enumeration in the TC and M3100 - for this we would need to deprecate the TC and define a new one - same with the object(s) using the TC. However, if we just want to add the missing value for reinitialize as April suggests and fix the comment which is obviously wrong I believe that the IANA mechanism would work. Regards, Dan -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn&lt; at &gt;mindspring.com] Sent: Mon 4/23/2012 8:35 PM To: Romascanu, Dan</pre> Randy Presuhn 2012-04-23T17:50:21 http://permalink.gmane.org/gmane.ietf.disman/1302 <pre>Well, yes, the resolution proposed to the errata was correct if we are to align the values of the enumeration in the TC and M3100 - for this we would need to deprecate the TC and define a new one - same with the object(s) using the TC. However, if we just want to add the missing value for reinitialize as April suggests and fix the comment which is obviously wrong I believe that the IANA mechanism would work. Regards, Dan -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn&lt; at &gt;mindspring.com] Sent: Mon 4/23/2012 8:35 PM To: Romascanu, Dan (Dan); April Pennisi Cc: disman&lt; at &gt;ietf.org Subject: Re: [Disman] Alarm Mib Hi - The omission was the subject of a proposed eratum reported July 29, 2009. Section 5.2 of RFC 3877 notwithstanding, the view that prevailed at the time was: "Technically the submitter is right. However, the change cannot be made the way suggested in the Errata, but only by deprecating the object and defining a new object with correct enumerated values. This can be d</pre> Romascanu, Dan (Dan 2012-04-23T17:40:16 http://permalink.gmane.org/gmane.ietf.disman/1301 <pre>Hi - The omission was the subject of a proposed eratum reported July 29, 2009. Section 5.2 of RFC 3877 notwithstanding, the view that prevailed at the time was: "Technically the submitter is right. However, the change cannot be made the way suggested in the Errata, but only by deprecating the object and defining a new object with correct enumerated values. This can be done only in a future version of the MIB module." This eventually concluded with a recommendation of "hold for document update." It looks like we, as a WG, may have blown it on this one. There are really two problems itentified in the original report: the missing enumeration value, and the wrong explanatory text. Both need to be fixed, and the IANA mechanism seems appropriate. Randy ----- Original Message ----- From: "Romascanu, Dan (Dan)" &lt;dromasca&lt; at &gt;avaya.com&gt; To: "April Pennisi" &lt;april.pennisi&lt; at &gt;genband.com&gt; Cc: &lt;disman&lt; at &gt;ietf.org&gt; Sent: Monday, April 23, 2012 5:46 AM Subject: Re: [Disman] Alarm Mib Hi April, I hope tha</pre> Randy Presuhn 2012-04-23T17:35:06 http://permalink.gmane.org/gmane.ietf.disman/1300 <pre>Hi April, I hope that you do not mind if I am copying the disman WG list. I do not remember why we skipped this value, it may just have been a miss. Maybe Sharon or Randy remember. In any case, according to section 5.2 in RFC 3877 this may be fixed rather easily by requesting to add one new enumerated value in the IANA maintained TC at http://www.iana.org/assignments/ianaitualarmtc-mib by sending a mail to iana&lt; at &gt;iana.org. Regards, Dan From: April Pennisi [mailto:april.pennisi&lt; at &gt;genband.com] Sent: Tuesday, April 10, 2012 1:02 AM To: Romascanu, Dan (Dan) Subject: Alarm Mib Hi Dan - I've been working on mapping alarms from a device to appropriate probable causes defined in RFC 3877. I notice there is one from M3100 missing from the list IANAItuProbableCause in the Alarm MIB. Reinitialized is missing. (It occurred to me because I'd like to use it.) From M3100: lossOfRealTime ProbableCause &lt;http://www.itu.int/ITU-T/formal-language/itu-t/x/x721/1992/Attribute-A</pre> Romascanu, Dan (Dan 2012-04-23T12:46:21 http://permalink.gmane.org/gmane.ietf.disman/1299 <pre>Hi - Fwd. FYI. Randy ----- Original Message ----- scheduling-related activities are as follows: Group session, use the IETF Meeting Session Request Tool. instructions on Requesting a BOF. Tool. Tool. Tool. Management Tool. submitting all of the information that the Secretariat requires to schedule your sessions. of the message, and include all of the information specified in item (4) of "Requesting Meeting Sessions at IETF Meetings" in the body. (This document is included below.) Draft Working Group agendas are due Wednesday, March 14, 2012 by 17:00 PT. Revised Working Group agendas are due no later than Monday, March 19, 2012 at 17:00 PT. The proposed agenda for a BOF session should be submitted along with your request for a session. Please be sure to copy your Area Director on that message. making your meeting agenda, minutes, and presentation slides available to the community before, during, and after an IETF meeting. If you are a BOF chair, then you may use the tool to submit a revised agenda as </pre> Randy Presuhn 2012-01-17T20:47:28 http://permalink.gmane.org/gmane.ietf.disman/1298 <pre>Hi - Forwarded for your information. Randy ----- Original Message ----- scheduling-related activities are as follows: Request Tool. Group session, use the IETF Meeting Session Request Tool. see instructions on Requesting a BOF. Tool. Tool. submitting all of the information that the Secretariat requires to schedule your sessions. of the message, and include all of the information specified in item (4) of "Requesting Meeting Sessions at IETF Meetings" in the body. (This document is included below.) Draft Working Group agendas are due Wednesday, November 2, 2011 by 17:00 PT. Revised Working Group agendas are due no later than Monday, November 7, 2011 at 17:00 PT. The proposed agenda for a BOF session should be submitted along with your request for a session. Please be sure to copy your Area Director on that message. making your meeting agenda, minutes, and presentation slides available to the community before, during, and after an IETF meeting. If you are a BOF chair, then you may use the tool to submit</pre> Randy Presuhn 2011-08-22T18:51:52 http://permalink.gmane.org/gmane.ietf.disman/1297 <pre>Hi - fwd fyi. Randy ----- Original Message ----- </pre> Randy Presuhn 2011-06-29T20:30:30 http://permalink.gmane.org/gmane.ietf.disman/1296 <pre>Hi - Fwd FYI. Randy ----- Original Message ----- </pre> Randy Presuhn 2011-06-27T03:50:15 http://permalink.gmane.org/gmane.ietf.disman/1295 <pre>Hi - Forwarded for your information, and to shake loose any "bouncers" from these mailing lists. Randy ----- Original Message ----- </pre> Randy Presuhn 2011-06-02T17:24:26 http://permalink.gmane.org/gmane.ietf.disman/1294 <pre>Hi - forwarded for your information, and to shake out dead addresses from these mailing lists. :-) Randy ----- Original Message ----- </pre> Randy Presuhn 2011-02-08T03:07:51 http://permalink.gmane.org/gmane.ietf.disman/1293 <pre> And InetAddress is encoded as an OCTET STRING and hence you should be fine using alarmActiveVariableOctetStringVal (and for the InetAddressType you would use alarmActiveVariableInteger32Val). /js </pre> Juergen Schoenwaelder 2011-01-31T08:17:15 http://permalink.gmane.org/gmane.ietf.disman/1292 <pre>Greetings, In the version of RFC 3877 available at datatracker.ietf.org, I noticed that the alarmActiveVariableValueType does not include either InetAddressType or InetAddress in the enumeration which does not allow you to indicate an IPv6 address in the alarmActiveVariableTable. The alarmActiveEngineAddress is expressed according to RFC 2851, so that is not a problem. Will alarmActiveVariableValueType be extended to include InetAddressType and InetAddress (along with matching alarmActiveVariableInetAddressTypeVal and alarmActiveVariableInetAddressVal objects in AlarmActiveVariableEntry)? Is there a recommended work-around? Thank you! </pre> Mark A. Flacy 2011-01-29T22:21:59 http://permalink.gmane.org/gmane.ietf.disman/1291 <pre>Hi - FWD FYI Randy ----- Original Message ----- -------------------------------------------------------------------------------- </pre> Randy Presuhn 2010-09-17T00:21:54 http://permalink.gmane.org/gmane.ietf.disman/1290 <pre>Hi - Forwarded for your information, in case you'd like to request a BOF. Randy </pre> Randy Presuhn 2010-06-09T19:26:15 http://permalink.gmane.org/gmane.ietf.disman/1289 <pre>(speaking as a contributor and co-author of RFC 3877) Our intention with ituAlarmTable was stated in 4.1.3 the states in terms of ITU perceived severity. and then in 5.1: possible alarms in the system. My recollection is that we did not seek exact emulation, but a mapping that makes sense for the severity levels. We looked at the ITU-T standards because we did not want to reinvent the wheel. I personally was not aware about the differences between M.3100 and X.733 on this respect, but frankly I was relying on Sharon who was at that time directly involved in the ITU-T work. Dan </pre> Romascanu, Dan (Dan 2010-05-13T07:14:22 http://permalink.gmane.org/gmane.ietf.disman/1288 <pre>Hi - ... Two observations: (1) The working group was specifically chartered: "The work on the Alarm MIB will take into consideration existing standards and practices, such as ITU-T X.733. Whether any mappings to these other standards appear in the Alarm MIB or in separate documents will be decided by the WG. The WG will actively seek participation from ITU participants to make ensure that the ITU work is correctly understood." So, I wondered, why does section 3.1 in its definition of "Alarm State" (NOT "Status") give M.3100 as an example rather than X.733? Turns out it was in response to my comment requesting that *a* reference be given (October 7, 2003) but there was no discussion whether one or the other would have been a better example to cite. (2) RFC3877 never mentions alarmStatus. Is your issue that you'd expect the ituAlarmTable in RFC 3877 to emulate the behaviour of an ITU (pick your standard) alarmStatus? Sharon, Dan, was that the intent? Randy</pre> Randy Presuhn 2010-05-12T18:23:11 http://permalink.gmane.org/gmane.ietf.disman/1287 <pre>Randy, I should have also given you the comment from the M.3100 GDMOS: </pre> Brian F. G. Bidulock 2010-05-12T12:01:05 http://permalink.gmane.org/gmane.ietf.disman/1286 <pre>Randy, On Tue, 11 May 2010, Randy Presuhn wrote: You still don't get it: I am not talking about enumerations of perceivedSeverity. I am talking about the severity levels of alarmStatus: This from the M.3100 GDMOs: (alarmStatus ATTRIBUTE DEFINED AS) "The Alarm Status attribute type indicates the occurrence of an abnormal condition relating to an object. This attribute may also function as a summary indicator of alarm conditions associated with a specific resource. It is used to indicate the existence of an alarm condition, a pending alarm condition such as threshold situations, or (when used as a summary indicator) the highest severity of active alarm conditions. When used as a summary indicator, the order of severity (from highest to lowest) is: activeReportable-Critical activeReportable-Major activeReportable-Minor activeReportable-Indeterminate activeReportable-Warning activePending cleared." And from the M.3100 ASN: AlarmStatus ::= ENUMERATED { clear</pre> Brian F. G. Bidulock 2010-05-12T11:45:30 http://permalink.gmane.org/gmane.ietf.disman/1285 <pre>Indeed - the confusion is mine and I apologize. Did the WG reach a recommendation for Errata #1652? I cannot find it in my archives. My opinion as a contributor is that we still better reject the errata but the comment should prompt on the discrepancy between the different standards, and show that it is not clear from the ITU-T standards the value 'indeterminate' should be used in ordering relative to the other levels and in masking. Brian, please submit again your errata - so that we can append the appropriate comment and resolution. Thanks and Regards, Dan </pre> Romascanu, Dan (Dan 2010-05-12T10:24:27 http://permalink.gmane.org/gmane.ietf.disman/1284 <pre>Brian, Please use my first name and not the family name. Thanks and Regards, Dan </pre> Romascanu, Dan (Dan 2010-05-12T10:11:13 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.disman