gmane.ietf.disman

Fw: CORRECTION: Help the NomCom

Randy Presuhn — 2012-11-01T18:46:51

Hi -

Forwarded for your information, and, hopefully, action.

Randy

----- Original Message ----- 
From: "NomCom Chair" <nomcom-chair< at >ietf.org>
To: "Working Group Chairs" <wgchairs< at >ietf.org>
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 Sunday, November 11.

The final list of candidates (as per RFC 5680) that the NomCom is 
considering for open positions can be found at: 
https://www.ietf.org/group/nomcom/2012/input/

The NomCom will be holding office hours during IETF 85, Monday-
Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes 
comments on specific individuals, as well as general feedback related to 
any of the positions that NomCom is considering.

Note: A list of leadership positions that the NomCom is considering can be 
found at: https://www.ietf.org/group/nomcom/2012/

If the NomCom office hours are inconvenient for you or if you cannot 
attend IETF 85, the NomCom is happy to take community input via email 
to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange a 
meeting outside of office hours, just send us email and we can set 
something up.

Comments on specific candidates can also be provided to the NomCom
via the web feedback tool: 
https://www.ietf.org/group/nomcom/2012/input/

Thank you for your help,
- Matt Lepinski
  nomcom-chair at ietf.org

Re: Alarm Mib

Randy Presuhn — 2012-04-23T17:50:21

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)" <dromasca< at >avaya.com>
To: "Randy Presuhn" <randy_presuhn< at >mindspring.com>; "April Pennisi" <april.pennisi< at >genband.com>
Cc: <disman< at >ietf.org>
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< at >mindspring.com]
Sent: Mon 4/23/2012 8:35 PM
To: Romascanu, Dan (Dan); April Pennisi
Cc: disman< at >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 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)" <dromasca< at >avaya.com>
To: "April Pennisi" <april.pennisi< at >genband.com>
Cc: <disman< at >ietf.org>
Sent: Monday, April 23, 2012 5:46 AM
Subject: Re: [Disman] Alarm Mib


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< at >iana.org.



Regards,



Dan







From: April Pennisi [mailto:april.pennisi< at >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
<http://www.itu.int/ITU-T/formal-language/itu-t/x/x721/1992/Attribute-AS
N1Module.html#Attribute-ASN1Module.ProbableCause>  ::=
  localValue:157

Re: Alarm Mib

Romascanu, Dan (Dan — 2012-04-23T17:40:16

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< at >mindspring.com]
Sent: Mon 4/23/2012 8:35 PM
To: Romascanu, Dan (Dan); April Pennisi
Cc: disman< at >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 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)" <dromasca< at >avaya.com>
To: "April Pennisi" <april.pennisi< at >genband.com>
Cc: <disman< at >ietf.org>
Sent: Monday, April 23, 2012 5:46 AM
Subject: Re: [Disman] Alarm Mib


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< at >iana.org. 

 

Regards,

 

Dan

 

 

 

From: April Pennisi [mailto:april.pennisi< at >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
<http://www.itu.int/ITU-T/formal-language/itu-t/x/x721/1992/Attribute-AS
N1Module.html#Attribute-ASN1Module.ProbableCause>  ::=
  localValue:157

Re: Alarm Mib

Randy Presuhn — 2012-04-23T17:35:06

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)" <dromasca< at >avaya.com>
To: "April Pennisi" <april.pennisi< at >genband.com>
Cc: <disman< at >ietf.org>
Sent: Monday, April 23, 2012 5:46 AM
Subject: Re: [Disman] Alarm Mib


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< at >iana.org. 

 

Regards,

 

Dan

 

 

 

From: April Pennisi [mailto:april.pennisi< at >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
<http://www.itu.int/ITU-T/formal-language/itu-t/x/x721/1992/Attribute-AS
N1Module.html#Attribute-ASN1Module.ProbableCause>  ::=
  localValue:157

Re: Alarm Mib

Romascanu, Dan (Dan — 2012-04-23T12:46:21

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< at >iana.org. 

 

Regards,

 

Dan

 

 

 

From: April Pennisi [mailto:april.pennisi< at >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
<http://www.itu.int/ITU-T/formal-language/itu-t/x/x721/1992/Attribute-AS
N1Module.html#Attribute-ASN1Module.ProbableCause>  ::=
  localValue:157

Fw: 83rd IETF - Working Group/BOF Scheduling REMINDER

Randy Presuhn — 2012-01-17T20:47:28

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 well as other materials for your BOF once the BOF
has been approved.
submitted.
Materials Management Tool." The same User ID and password will work for both tools. If you are a BOF chair who is not also a
Working Group chair, then you will be given an account on the "IETF Meeting Materials Management Tool" when your BOF has been
approved. If you require assistance in using either tool, or wish to report a bug, then please send a message to:
for submitting all of the information required by the Secretariat to schedule your sessions. The URL for the tool is:
unable to use the tool, then you may send your request via e-mail to agenda< at >ietf.org, with a copy to the appropriate Area
Director(s).
line.
Area Director, preferably well in advance of the BOF approval deadline date. The AD needs to have the full name of the BOF, its
acronym, suggested names of chairs, an agenda, full description of the BOF and the information covered in item 4. Please read RFC
5434 for instructions on how to drive a successful BOF effort. The approval depends on, for instance, Internet-Drafts and list
discussion on the suggested topic. BOF agenda requests, if approved, will be submitted to the IETF Secretariat by the ADs.
request must be approved by an Area Director. Additional sessions will be assigned, based on availability, after Monday, February
27, 2012 at 17:00 PT, the cut-off date for requests to reschedule a session.
Guidelines and Procedures" (http://www.ietf.org/rfc/rfc2418.txt).

Fw: 82nd IETF - Working Group/BOF Scheduling

Randy Presuhn — 2011-08-22T18:51:52

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 a revised agenda as well as other materials for your BOF once the BOF
has been approved.
submitted.
Materials Management Tool." The same User ID and password will work for both tools. If you are a BOF chair who is not also a
Working Group chair, then you will be given an account on the "IETF Meeting Materials Management Tool" when your BOF has been
approved. If you require assistance in using either tool, or wish to report a bug, then please send a message to:
for submitting all of the information required by the Secretariat to schedule your sessions. The URL for the tool is:
unable to use the tool, then you may send your request via e-mail to agenda< at >ietf.org, with a copy to the appropriate Area
Director(s).
line.
CHAIR(S) NAME(S) (given together with e-mail address(es)), AN AGENDA AND FULL DESCRIPTION, and the information requested in (4)
below. (Please read the BOF Procedure at: http://www.ietf.org/ietf/1bof-procedures.txt before requesting a session for a BOF.)
request must be approved by an Area Director. Additional sessions will be assigned, based on availability, after Monday, October
17, 2011 at 17:00 PT, the cut-off date for requests to reschedule a session.
Guidelines and Procedures" (http://www.ietf.org/rfc/rfc2418.txt).

Fw: Internet Draft Initial Version (-00) Cut-Off Monday,July 4

Randy Presuhn — 2011-06-29T20:30:30

Hi -

fwd fyi.

Randy

----- Original Message -----

Fw: Please help the Nomcom

Randy Presuhn — 2011-06-27T03:50:15

Hi -

Fwd FYI.

Randy

----- Original Message -----

Fw: 81th IETF - Working Group/BOF Scheduling - REMINDER

Randy Presuhn — 2011-06-02T17:24:26

Hi -

Forwarded for your information, and to shake loose any "bouncers"
from these mailing lists.

Randy

----- Original Message -----

Fw: 80th IETF - Working Group/BOF Scheduling REMINDER

Randy Presuhn — 2011-02-08T03:07:51

Hi -

forwarded for your information, and to shake out dead
addresses from these mailing lists.  :-)

Randy

----- Original Message -----

Re: RFC 3877 and IPv6

Juergen Schoenwaelder — 2011-01-31T08:17:15

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

RFC 3877 and IPv6

Mark A. Flacy — 2011-01-29T22:21:59

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!

Fw: NomCom 2010-2011: Call for More Nominations

Randy Presuhn — 2010-09-17T00:21:54

Hi -

FWD FYI

Randy

----- Original Message ----- 


--------------------------------------------------------------------------------

Fw: 78th IETF - Working Group - REMINDER

Randy Presuhn — 2010-06-09T19:26:15

Hi -

Forwarded for your information, in case you'd like to request a BOF.

Randy

Re: [Errata Rejected] RFC3877 (1652)

Romascanu, Dan (Dan — 2010-05-13T07:14:22

(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

Re: [Errata Rejected] RFC3877 (1652)

Randy Presuhn — 2010-05-12T18:23:11

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

Re: [Errata Rejected] RFC3877 (1652)

Brian F. G. Bidulock — 2010-05-12T12:01:05

Randy,

I should have also given you the comment from the M.3100 GDMOS:

Re: [Errata Rejected] RFC3877 (1652)

Brian F. G. Bidulock — 2010-05-12T11:45:30

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 {
cleared(0),
activeReportable-Indeterminate(1),
activeReportable-Warning(2),
activeReportable-Minor(3),
activeReportable-Major(4),
activeReportable-Critical(5),
activePending(6) }

Now, just in the MIB:

    "Entries appear in this table whenever an entry is created
     in the alarmModelTable with a value of alarmModelState in
     the range from 1 to 6.  Entries disappear from this table
     whenever the corresponding entries are deleted from the
     alarmModelTable, including in cases where those entries
     have been deleted due to local system action.  The value of
     alarmModelSpecificPointer has no effect on the creation
     or deletion of entries in this table.  Values of
     alarmModelState map to values of ituAlarmPerceivedSeverity
     as follows:

       alarmModelState -> ituAlarmPerceivedSeverity
      1        ->         clear (1)
      2        ->         indeterminate (2)
      3        ->         warning (6)
      4        ->         minor (5)
      5        ->         major (4)
      6        ->         critical (3)

     All other values of alarmModelState MUST NOT appear
     in this table.

And alarmModelState

        "A value of 1 MUST indicate a clear alarm state.
        The value of this object MUST be less than the
        alarmModelState of more severe alarm states for
        this alarm.  The value of this object MUST be more
        than the alarmModelState of less severe alarm states
        for this alarm."


So, the alarm model state values must be ordered in order of severity,
otherwise, masking occurs.  However, the alarmModelState value
mapping from perceivedSeverity do no match the M.3100 alarmStatus
severity levels.  INDETERMINATE AND WARNING ARE REVERSED.  Therefore
the mapping does not follow the MUST rules for alarmModelState per
M.3100 alarmStatus which is NOT the same as the X.721 alarmStatus.


See M.3100 alarmStatus, per above.  Because the alarmModelState
rule (MUST) is violated, and alarm of activeReportable-Warning
will mask more severe alarms of activeReportable-Indeterminate.



Again, read my lips: not perceivedSeverity enumerations, but
M.3100 alarmStatus to alarmModelState mapping.

--brian

Re: [Errata Rejected] RFC3877 (1652)

Romascanu, Dan (Dan — 2010-05-12T10:24:27

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

Re: [Errata Rejected] RFC3877 (1652)

Romascanu, Dan (Dan — 2010-05-12T10:11:13

Brian,

Please use my first name and not the family name. 

Thanks and Regards,

Dan