headers
Sharon Chisholm | 2 Nov 2003 11:28

RE: Closed item from Randy's Review

Hi

Current Score:

The following items are closed:

1-10, 13, 15-23, 25, 27, 29-34, 36-38, 40-41, 45-46, 48, 50-54, 57, 60-61,
64, 67, 69-2, 70, 72-73, 74, 75-3

The following items are conditionally closed:

11, 12, 14, 17, 24, 28, 35, 42-44, 49, 56, 58, 62-63, 65-66, 71, 75-1,
N+1,N+2,
N+3 

The following items are still be processed:

26, 39, 47, 55, 59, 65, 68, 69-1, 75-2, 75-4 

Sharon

-----Original Message-----
From: Chisholm, Sharon [CAR:0S00:EXCH] 
Sent: Wednesday, October 15, 2003 12:37 PM
To: Disman (E-mail)
Subject: RE: [Disman] Closed item from Randy's Review

Hi

For those keeping score at home, this is where we stand:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sharon Chisholm | 2 Nov 2003 11:58

RE: alarm comment 69-1

hi

The following is the proposed resolution to Randy-69-1  Assuming no 
objection, this item will be considered closed conditional on the 
proposed edit being done.

Replace

   ituAlarmEntry OBJECT-TYPE
      SYNTAX      ItuAlarmEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "Entries appear in this table for each possible alarm
           severity.
           This table MUST be persistent across system reboots."
      INDEX       { alarmListName, alarmModelIndex,
                   ituAlarmPerceivedSeverity }
      ::= { ituAlarmTable 1 }

With

   ituAlarmEntry OBJECT-TYPE
      SYNTAX      ItuAlarmEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "Entries appear in this table for each possible alarm
           severity. For each entry created/deleted in the 
           alarmModeTable an entry in this table is created/deleted
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sharon Chisholm | 2 Nov 2003 12:17

RE: ituAlarmGenericModel is redundant?

Hi

The following is the proposed resolution to Randy-68  Assuming no 
objection, this item will be considered closed conditional on the 
proposed edit being done.

In the description of ituAlarmGenericModel 
      "This object points to the corresponding
      row in the alarmModelTable for this alarm severity."

With
      "This object points to the corresponding
      row in the alarmModelTable for this alarm severity.

      This corresponding entry to alarmModelTable could also
      be derived by performing the reverse of the mapping
      from alarmModelState to ituAlarmPerceivedSeverity defined 
      in the description of ituAlarmEntry to determine the 
      appropriate { alarmListName, alarmModelIndex, alarmModelState }
      for this { alarmListName, alarmModelIndex, 
      ituAlarmPerceivedSeverity }."

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:randy_presuhn <at> mindspring.com] 
Sent: Friday, October 24, 2003 6:48 PM
To: Chisholm, Sharon [CAR:0S00:EXCH]; Disman (E-mail)
Subject: Re: [Disman] ituAlarmGenericModel is redundant?
(Continue reading)

Permalink | Reply | 8 comments |
headers
Sharon Chisholm | 2 Nov 2003 12:26

RE: Section 4.1.5 in draft-ietf-disman-alarm-mib-15.txt

Hi

The following is the proposed resolution to Randy-39  Assuming no 
objection, this item will be considered closed conditional on the 
proposed edit being done.

In section 4.1.5, replace:

"  The alarm model table can, and probably should, be initially
   populated by the system. The objects in alarmModelTable and
   ituAlarmTable have a MAX-ACCESS of read-write, which allows managers
   to modify the alarm models to suit their requirements."

 With
   "The alarm model table SHOULD be initially
   populated by the system. The objects in alarmModelTable and
   ituAlarmTable have a MAX-ACCESS of read-create, which allows managers
   to modify the alarm models to suit their requirements."

Sharon
-----Original Message-----
From: Randy Presuhn [mailto:randy_presuhn <at> mindspring.com] 
Sent: Thursday, October 16, 2003 12:08 PM
To: Disman (E-mail)
Subject: Re: [Disman] Section 4.1.5 in draft-ietf-disman-alarm-mib-15.txt

Hi -

> From: "Sharon Chisholm" <schishol <at> nortelnetworks.com>
> To: "Disman (E-mail)" <disman <at> ietf.org>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sharon Chisholm | 2 Nov 2003 12:32

RE: Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt

Hi

The following is the proposed resolution to Randy-26  Assuming no objection,
this item will be considered closed conditional on the proposed edit being
done.

In section 3.3.5 replace

 "   The Alarm MIB provides a generic method for identifying the resource
    by extracting and building a resource ID from the Notification
    varbinds. Solutions interested in being able to differentiate the
    source of the alarm by means other than the source IP address and
    resource ID should create separate alarm lists such that each
    context/source IP address pair is its own list."

 With

    "The Alarm MIB provides a generic method for identifying the resource
    by extracting and building a resource ID from the Notification
    varbinds.  It records the relevant information needed to locate the
    source of the alarm."

Sharon

-----Original Message-----
From: Chisholm, Sharon [CAR:0S00:EXCH] 
Sent: Friday, October 17, 2003 7:53 AM
To: Disman (E-mail)
Subject: RE: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt
(Continue reading)

Permalink | Reply | 9 comments |
headers
Sharon Chisholm | 2 Nov 2003 12:36

RE: alarmActiveContextName in draft-ietf-disman-alarm-m ib-15.txt

Hi

The following is the proposed resolution to Randy-59  Assuming no objection,
this item will be considered closed conditional on the proposed edit being
done.

In the description of alarmActiveContextName replace

          "The name of the SNMP MIB context from which the alarm came.
          For SNMPv1 alarms this is the community string from the Trap.
          Note that care needs to be taken when selecting community
          strings to ensure that these can be represented as a
          well-formed SnmpAdminString.

          If the alarm's source SNMP engine is known not to support
          multiple contexts, this object is a zero length string."

With

          "The name of the SNMP MIB context from which the alarm came.
          For SNMPv1 alarms this is the community string from the Trap.
          Note that care MUST be taken when selecting community
          strings to ensure that these can be represented as a
          well-formed SnmpAdminString. Community or Context names
          that are not well-formed SnmpAdminStrings will be mapped
          to zero length strings.

          If the alarm's source SNMP engine is known not to support
          multiple contexts, this object is a zero length string."
(Continue reading)

Permalink | Reply | 7 comments |
headers
Randy Presuhn | 3 Nov 2003 18:20
Picon

changes to MIB IPR boilerplate

Hi -

The IESG has announced a change to the copyright notice that needs to be
embedded in MIB MODULE-IDENTITY sections.  The change was described
in the IESG announcement.  The relevant portion follows:

> From: "The IESG" <iesg-secretary <at> ietf.org>
> To: <IETF-Announce:>
> Cc: "Internet Architecture Board" <iab <at> iab.org>; "RFC Editor" <rfc-editor <at> rfc-editor.org>; <ipr-wg <at> ietf.org>
> Sent: Monday, November 03, 2003 12:27 PM
> Subject: Protocol Action: 'IETF Rights in Contributions' to BCP
...
> RFC EDITOR NOTE:
>
> In section 5.6 of draft-ietf-ipr-submission-rights, please make the
> following changes:
>
> OLD:
>
>          "Copyright (C) The Internet Society <year>.  The initial
>          version of this MIB module was published in RFC XXXX; for full
>          legal notices see the RFC itself or see:
>          http://www.ietf.org/copyrights/ianamib.html."
>
> NEW:
>
>          "Copyright (C) The Internet Society <year>.  The initial
>          version of this MIB module was published in RFC XXXX; for full
>          legal notices see the RFC itself. Supplementary information
>          may be available on http://www.ietf.org/copyrights/ianamib.html."
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randy Presuhn | 8 Nov 2003 04:29
Picon

Re: alarm comment 69-1

Hi -

> From: "Sharon Chisholm" <schishol <at> nortelnetworks.com>
> To: "Disman (E-mail)" <disman <at> ietf.org>
> Sent: Sunday, November 02, 2003 2:58 AM
> Subject: RE: [Disman] alarm comment 69-1
>

> hi
>
> The following is the proposed resolution to Randy-69-1  Assuming no
> objection, this item will be considered closed conditional on the
> proposed edit being done.
>
> Replace
>
>
>    ituAlarmEntry OBJECT-TYPE
>       SYNTAX      ItuAlarmEntry
>       MAX-ACCESS  not-accessible
>       STATUS      current
>       DESCRIPTION
>           "Entries appear in this table for each possible alarm
>            severity.
>            This table MUST be persistent across system reboots."
>       INDEX       { alarmListName, alarmModelIndex,
>                    ituAlarmPerceivedSeverity }
>       ::= { ituAlarmTable 1 }
>
> With
(Continue reading)

Permalink | Reply | 0 comments |
headers
Romascanu, Dan (Dan | 8 Nov 2003 23:52
Favicon

RE: alarm comment 69-1

> Let's see if I understand this correctly.  If a system 
> supports the ituAlarmTable,
> then whenever an entry is created (whether by user or by 
> system) in the
> alarmModelTabel with an alarmModelState value of 1, 2, 3, 4, 
> 5, or 6, then
> a corresponding entry will appear in the ituAlarmTable.  
> Likewise, whenever
> an entry is deleted from the ituAlarmTable, and that entry 
> has an alarmModelState
> value of 1..6, any corresponding entry will disappear from 
> the ituAlarmTable.
> So far, so good?

yes.

> 
> Here's my problem: if the system also supports some other 
> extension model which
> does not necessarily map to the ITU model, then even if that 
> model is able to
> avoid alarmModelState values of 2, 3, 4, 5, and 6, I don't 
> see how it could avoid
> using alarmModelState value 1, and consequently ending up 
> with entries in both
> the ituAlarmTable as well as this other extension table for 
> alarmModelState 1.
> Do you consider this to be a feature rather than a bug?

A feature. 'A value of 1 (for alarmModelState) MUST indicate a clear alarm state'. Concurrent specific
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randy Presuhn | 9 Nov 2003 22:34
Picon

RE: alarm comment 69-1

Hi -

> From: "Romascanu, Dan (Dan)" <dromasca <at> avaya.com>
> Sent: Nov 8, 2003 4:52 PM
> To: Randy Presuhn <randy_presuhn <at> mindspring.com>,
>	"Disman (E-mail)" <disman <at> ietf.org>
> Subject: RE: [Disman] alarm comment 69-1
...
> A feature. 'A value of 1 (for alarmModelState) MUST indicate a clear alarm state'.
> Concurrent specific models MAY support a clear alarm state. 
...

It'd be very difficult to define an extension model without a clear state, since that
notion is built into both the alarmModelTable and the alarmClearTable.  Anyway,
in a case like this, where there would be entries in both extension tables,
to which one would the alarmModelSpecificPointer point?

Randy
Permalink | Reply | 0 comments |

Gmane