Subject: Distributed Active Alarms

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 17 Jul 2000 14:25:05 -0400

hi

Here is some work I have done which applies the infrastructure used
in the Notification Log MIB to a different problem.  The problem it
is trying to address is the fact there is no standard way to determine
device alarm state when you first discover it, or after you regain
communication with it after a communication blackout.

The format is still a bit rough, but is hopefully readable.  I think
this work makes sense within this working group, so hopefully this
is something you find interesting enough for us to proceed with.

Please let me know what you think.

Sharon Chisholm
Preside Management
Nortel Networks
Ottawa, Ontario

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

						Sharon Chisholm
						Nortel Networks
						July 17, 2000

				Active Alarm MIB		

Status of this Memo

This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.

1. Abstract

   This memo defines a portion of the Management Information Base (MIB) for
use with 
   network management protocols in the Internet community.  In particular,
it 
   describes management objects used for maintaining a list of alarms
currently
   active on a network element.

2.  The SNMP Management Framework

   The SNMP Management Framework presently consists of five major
   components:

    o   An overall architecture, described in RFC 2571 [RFC2571].

    o   Mechanisms for describing and naming objects and events for the
        purpose of management.  The first version of this Structure of
        Management Information (SMI) is called SMIv1 and described in
        STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
        1215 [RFC1215].  The second version, called SMIv2, is described
        in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and
        STD 58, RFC 2580 [RFC2580].

    o   Message protocols for transferring management information.  The
        first version of the SNMP message protocol is called SNMPv1 and
        described in STD 15, RFC 1157 [RFC1157].  A second version of
        the SNMP message protocol, which is not an Internet standards
        track protocol, is called SNMPv2c and described in RFC 1901
        [RFC1901] and RFC 1906 [RFC1906].  The third version of the
        message protocol is called SNMPv3 and described in RFC 1906
        [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].

    o   Protocol operations for accessing management information.  The
        first set of protocol operations and associated PDU formats is
        described in STD 15, RFC 1157 [RFC1157].  A second set of
        protocol operations and associated PDU formats is described in
        RFC 1905 [RFC1905].

    o   A set of fundamental applications described in RFC 2573
        [RFC2573] and the view-based access control mechanism described
        in RFC 2575 [RFC2575].

   A more detailed introduction to the current SNMP Management Framework
   can be found in RFC 2570 [RFC2570].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo specifies a MIB module that is compliant to the SMIv2.  A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations.  The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no
   translation is possible (use of Counter64).  Some machine readable
   information in SMIv2 will be converted into textual descriptions in
   SMIv1 during the translation process.  However, this loss of machine
   readable information is not considered to change the semantics of the
   MIB.

3. Introduction

   It is intended that the active alarm table be queried upon device
discovery
   and rediscovery to determine which faults are currently active on the
device.
   This allows the network management station to find out about any faults
that
   may have occurred before it started managing a particular network
element, or
   while it was out of contact with it.

   Each alarm should have a corresponding clear which removes it from the 
   active alarm table, or is should be aged out.  The configuring and
   querying of alarm age-outs is not covered in this document.

   The active alarm Table is defined in a manner very similar to the
   log table in the notification log MIB.  This format allows the
   storage of any NOTIFICATION that can be defined using the ASN.1
   syntax.

4. Relation to notification log MIB

   This MIB is intended to compliment the notification log MIB, but
   can be used independently.  The current MIB syntax does require
   the importation of the notification log MIB in order to re-use
   nlmLogName.  

5. Definitions

ACTIVE-ALARM-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE,
    experimental, Integer32, Unsigned32,
    TimeTicks, Counter32, Counter64,
    IpAddress, Opaque                   FROM SNMPv2-SMI
    TimeStamp, DateAndTime,
    StorageType, RowStatus              FROM SNMPv2-TC
    SnmpAdminString, SnmpEngineID       FROM SNMP-FRAMEWORK-MIB
    MODULE-COMPLIANCE, OBJECT-GROUP     FROM SNMPv2-CONF   
    nlmLogName							FROM
NOTIFICATION-LOG-MIB; 
 
   activeAlarm MODULE-IDENTITY
       LAST-UPDATED "000005290000Z"
       ORGANIZATION "Active Alarm MIB"
       CONTACT-INFO
               "   Sharon Chisholm
                   Nortel Networks
                   PO Box 3511 Station C
                   Ottawa, Ont.  K1Y 4H7
                   Canada

                   [email-masked]"
       DESCRIPTION
               "The MIB module describes a generic solution
               to improve the reliability of SNMP traps by storing the
               current list of active alarms."
       ::= { somewhere XX }

--
-- Active Alarm Table
--     

activeAlarmObjects OBJECT IDENTIFIER ::= { activeAlarm 1 }

activeAlarmTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF ActiveAlarmEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A table of Active Alarms entries."
    ::= { activeAlarmObjects 1 }

activeAlarmEntry OBJECT-TYPE
    SYNTAX      ActiveAlarmEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Entries appear in this table when faults are active.  They are
        removed when the fault is not longer occurring."
    INDEX       { nlmLogName, activeAlarmIndex }
    ::= { activeAlarmTable 1 }

ActiveAlarmEntry ::= SEQUENCE {
    activeAlarmIndex                 Unsigned32,
    activeAlarmTime                  TimeStamp,
    activeAlarmDateAndTime           DateAndTime,
    activeAlarmEngineID              SnmpEngineID,
    activeAlarmContextName           SnmpAdminString,
    activeAlarmVariables             Unsigned32,
    activeAlarmNotificationID        OBJECT IDENTIFIER,
    activeAlarmLogIndex	  	  		 Unsigned32
}

activeAlarmIndex OBJECT-TYPE
    SYNTAX     Unsigned32 (1..4294967295)
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
        "A monotonically increasing integer which acts as the 
        index of entries within the named alarm list.  It wraps
        back to 1 after it reaches its maximum value."
    ::= { activeAlarmEntry 1 }

activeAlarmTime OBJECT-TYPE
    SYNTAX      TimeStamp
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The value of sysUpTime when the alarm occurred. Alarms get
        cleared and resent if still applicable at reboot, so this value
        is always a valid sysUptime."
    ::= { activeAlarmEntry 2 }

activeAlarmDateAndTime OBJECT-TYPE
    SYNTAX      DateAndTime
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The local date and time when the alarm occurred, instantiated
        only by systems that have date and time capability."
    ::= { activeAlarmEntry 3 }

activeAlarmEngineID OBJECT-TYPE
    SYNTAX      SnmpEngineID
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The identification of the SNMP engine at which the alarm
        originated.
        If the alarm list can contain Notifications from only one engine
        or the Trap is from an SNMPv1 system, this object is not
        instantiated."
    ::= { activeAlarmEntry 4 }

activeAlarmContextName OBJECT-TYPE
    SYNTAX      SnmpAdminString
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The name of the SNMP MIB context from which the alarm came.
        For SNMPv1 Traps this is the community string from the Trap.
        If the alarm's source SNMP engine is known not to support
        multiple contexts, this object is not instantiated."
    ::= { activeAlarmEntry 5 }

activeAlarmVariables OBJECT-TYPE
    SYNTAX      Unsigned32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The number of variables in activeAlarmVariableTable for this
        Notification."
    ::= { activeAlarmEntry 6 }

activeAlarmNotificationID OBJECT-TYPE
    SYNTAX      OBJECT IDENTIFIER
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The NOTIFICATION-TYPE object identifier of the Notification that
        occurred."
    ::= { activeAlarmEntry 7 }

activeAlarmLogIndex OBJECT-TYPE
    SYNTAX     Unsigned32 (0..4294967295)
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
        "This number can be considered a sequence number for the trap.
	It should be the same of the log index in the notification log MIB,
	if used.  If no log index or sequence number applies to the trap,
	then this object should have the value of 0."
    ::= { activeAlarmEntry 8 }

--
-- Active Alarm Variable Table
--

activeAlarmVariableTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF ActiveAlarmVariableEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A table of variables to go with active alarm entries."
    ::= { activeAlarmObjects 2 }

activeAlarmVariableEntry OBJECT-TYPE
    SYNTAX      ActiveAlarmVariableEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Entries appear in this table when there are variables in
        the varbind list of a corresponding alarm in activeAlarmTable."
    INDEX       {  activeAlarmIndex, activeAlarmVariableIndex }
    ::= { activeAlarmVariableTable 1 }

ActiveAlarmVariableEntry ::= SEQUENCE {
    activeAlarmVariableIndex                 Unsigned32,
    activeAlarmVariableID                    OBJECT IDENTIFIER,
    activeAlarmVariableValueType             INTEGER,
    activeAlarmVariableCounter32Val          Counter32,
    activeAlarmVariableUnsigned32Val         Unsigned32,
    activeAlarmVariableTimeTicksVal          TimeTicks,
    activeAlarmVariableInteger32Val          Integer32,
    activeAlarmVariableOctetStringVal        OCTET STRING,
    activeAlarmVariableIpAddressVal          IpAddress,
    activeAlarmVariableOidVal                OBJECT IDENTIFIER,
    activeAlarmVariableCounter64Val          Counter64,
    activeAlarmVariableOpaqueVal             Opaque
}

activeAlarmVariableIndex OBJECT-TYPE
    SYNTAX     Unsigned32 (1..4294967295)
    MAX-ACCESS not-accessible
    STATUS     current
    DESCRIPTION
        "A monotonically increasing integer, starting at 1 for a given
        activeAlarmIndex, for indexing variables within the active
        alarm list."
    ::= { activeAlarmVariableEntry 1 }

activeAlarmVariableID OBJECT-TYPE
    SYNTAX     OBJECT IDENTIFIER
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
        "The variable's object identifier."
    ::= { activeAlarmVariableEntry 2 }

activeAlarmVariableValueType OBJECT-TYPE
    SYNTAX      INTEGER { counter32(1), unsigned32(2), timeTicks(3),
                          integer32(4), ipAddress(5), octetString(6),
                          objectId(7), counter64(8), opaque(9) }
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The type of the value.  One and only one of the value
        objects that follow is used, based on this type."
    ::= { activeAlarmVariableEntry 3 }

activeAlarmVariableCounter32Val OBJECT-TYPE
    SYNTAX      Counter32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The value when activeAlarmVariableType is 'counter32'."
    ::= { activeAlarmVariableEntry 4 }

activeAlarmVariableUnsigned32Val OBJECT-TYPE
    SYNTAX      Unsigned32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The value when activeAlarmVariableType is 'unsigned32'."
    ::= { activeAlarmVariableEntry 5 }

activeAlarmVariableTimeTicksVal OBJECT-TYPE
    SYNTAX      TimeTicks
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The value when activeAlarmVariableType is 'timeTicks'."
    ::= { activeAlarmVariableEntry 6 }

activeAlarmVariableInteger32Val OBJECT-TYPE
    SYNTAX      Integer32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The value when activeAlarmVariableType is 'integer32'."
    ::= { activeAlarmVariableEntry 7 }

activeAlarmVariableOctetStringVal OBJECT-TYPE
    SYNTAX      OCTET STRING
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The value when activeAlarmVariableType is 'octetString'."
    ::= { activeAlarmVariableEntry 8 }

activeAlarmVariableIpAddressVal OBJECT-TYPE
    SYNTAX      IpAddress
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The value when activeAlarmVariableType is 'ipAddress'."
    ::= { activeAlarmVariableEntry 9 }

activeAlarmVariableOidVal OBJECT-TYPE
    SYNTAX      OBJECT IDENTIFIER
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The value when activeAlarmVariableType is 'objectId'."
    ::= { activeAlarmVariableEntry 10 }

activeAlarmVariableCounter64Val OBJECT-TYPE
    SYNTAX      Counter64
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The value when activeAlarmVariableType is 'counter64'."
    ::= { activeAlarmVariableEntry 11 }

activeAlarmVariableOpaqueVal OBJECT-TYPE
    SYNTAX      Opaque
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The value when activeAlarmVariableType is 'opaque'."
    ::= { activeAlarmVariableEntry 12 }        
    
--
-- Statistics
--
activeAlarmStatsTable  OBJECT-TYPE
       SYNTAX  SEQUENCE OF ActiveAlarmStatsEntry
       MAX-ACCESS  not-accessible
       STATUS  current
       DESCRIPTION
          "This table represents the alarm statistics type information." 
        ::= { activeAlarmObjects 3 }

   activeAlarmStatsEntry OBJECT-TYPE
       SYNTAX  ActiveAlarmStatsEntry
       MAX-ACCESS  not-accessible
       STATUS  current
       DESCRIPTION
          "Statistics on the current active alarms."

       INDEX   { nlmLogName }

        ::= {  activeAlarmStatsTable 1 }

   ActiveAlarmStatsEntry ::=
       SEQUENCE {
            activeAlarmStatsTotalActive    Unsigned32
                 }

  activeAlarmStatsTotalActive OBJECT-TYPE
       SYNTAX Unsigned32 
       MAX-ACCESS read-only
       STATUS  current
       DESCRIPTION
          "The total number of currently active alarms on the system." 

        ::= { activeAlarmStatsEntry 1 }

     -- Conformance Stuff
     
     activeAlarmConformance OBJECT IDENTIFIER ::= { activeAlarm 2 }

	 activeAlarmListGroup OBJECT-GROUP
	 	  OBJECTS { 
    		activeAlarmIndex,
    		activeAlarmTime,
    		activeAlarmDateAndTime,
    		activeAlarmEngineID,
    		activeAlarmContextName,
    		activeAlarmVariables,
    		activeAlarmNotificationID,
    		activeAlarmLogIndex,
    		activeAlarmVariableIndex,
    		activeAlarmVariableID,
    		activeAlarmVariableValueType,
    		activeAlarmVariableCounter32Val,
    		activeAlarmVariableUnsigned32Val,
    		activeAlarmVariableTimeTicksVal,
    		activeAlarmVariableInteger32Val,
    		activeAlarmVariableOctetStringVal,
    		activeAlarmVariableIpAddressVal,
    		activeAlarmVariableOidVal,
    		activeAlarmVariableCounter64Val,
    		activeAlarmVariableOpaqueVal	 	  
	 	  	} 
	 	   STATUS   current
           DESCRIPTION
                "Active Alarm list group."
           ::= { activeAlarmConformance 2}
    
     activeAlarmSummaryGroup  OBJECT-GROUP
           OBJECTS  {
                    activeAlarmStatsTotalActive
                     }
           STATUS   current
           DESCRIPTION
                " Active alarm summary group."
           ::= { activeAlarmConformance 3}

activeAlarmCompliance MODULE-COMPLIANCE
       STATUS  current
       DESCRIPTION
           "The compliance statement for systems supporting Active Alarm
MIB."  
       MODULE -- this module      
           MANDATORY-GROUPS {
            activeAlarmListGroup
           }  
           GROUP activeAlarmSummaryGroup  
           DESCRIPTION
           "The actual active alarms."

	::= { activeAlarmConformance 1 }
	
END 
	
6. Example

	Define the following Object:
	  acmeWidgetIndex OBJECT-TYPE
	    SYNTAX  Integer32
	    MAX-ACCESS read-only
	    STATUS   current
	    DESCRIPTION
	      "A unique number which identifies a particular Widget."
	  ::= { acmeWidgetEntry 1 }
	    
	Define the following three traps:
	  acmeWidgetTemperatureCritical NOTIFICATION-TYPE
	    OBJECTS { acmeWidgetIndex }
	    STATUS	current
	    DESCRIPTION
	      "This trap indicates that the indicated
		widget has reached a critical temperature."
	  ::= { acmeWidgetTraps 1 }

	  acmeWidgetTemperatureNormal NOTIFICATION-TYPE
	    OBJECTS { acmeWidgetIndex }
	    STATUS	current
	    DESCRIPTION
	      "This trap indicates that the indicated widget has
		reached a normal temperature."
	  ::= { acmeWidgetTraps 2 }

	  bgpBackwardTransition NOTIFICATION-TYPE
            OBJECTS { bgpPeerLastError,
                      bgpPeerState      }
            STATUS  current
            DESCRIPTION
               "The BGPBackwardTransition Event is generated
               when the BGP FSM moves from a higher numbered
               state to a lower numbered state."
           ::= { bgpTraps 2 }

	0. Active alarm table empty and nothing in notification log
		 ___________________________      _____________________
		| activeAlarmTable          |    | nlmLogTable         |
		|---------------------------|    |---------------------|
		| activeAlarmIndex |  alarm |    | nlmLogIndex | alarm |
		|---------------------------|    |---------------------|
		|___________________________|    |_____________________|

	1. Temperature of widget 2 goes critical
		 __________________________________________________
		| activeAlarmTable                                 |    
		|--------------------------------------------------|    
		| activeAlarmIndex |  alarm                        |    
		|--------------------------------------------------|    
		|        1         | acmeWidgetTemperatureCritical |
		|__________________________________________________|  

		 _____________________________________________
		| nlmLogTable                                 |    
		|---------------------------------------------|    
		| nlmLogIndex |  alarm                        |    
		|---------------------------------------------|    
		|      1      | acmeWidgetTemperatureCritical |
		|_____________________________________________|  

	2. BGP peering session transitions from a state of established to
opensent
		 __________________________________________________
		| activeAlarmTable                                 |    
		|--------------------------------------------------|    
		| activeAlarmIndex |  alarm                        |    
		|--------------------------------------------------|    
		|        1         | acmeWidgetTemperatureCritical |
		|        2         | bgpBackwardTransition         |
		|__________________________________________________|  

		 _____________________________________________
		| nlmLogTable                                 |    
		|---------------------------------------------|    
		| nlmLogIndex |  alarm                        |    
		|---------------------------------------------|    
		|      1      | acmeWidgetTemperatureCritical |
		|      2      | bgpBackwardTransition         |
		|_____________________________________________|  

	3. Temperature of widget 2 goes back to normal
		 __________________________________________________
		| activeAlarmTable                                 |    
		|--------------------------------------------------|    
		| activeAlarmIndex |  alarm                        |    
		|--------------------------------------------------|    
		|        2         | bgpBackwardTransition         |
		|__________________________________________________|  

		 _____________________________________________
		| nlmLogTable                                 |    
		|---------------------------------------------|    
		| nlmLogIndex |  alarm                        |    
		|---------------------------------------------|    
		|      1      | acmeWidgetTemperatureCritical |
		|      2      | bgpBackwardTransition         |
		|      3      | acmeWidgetTemperatureNormal   |
		|_____________________________________________|  

	4. Time passes .... BGP alarm ages out.

		 __________________________________________________
		| activeAlarmTable                                 |    
		|--------------------------------------------------|    
		| activeAlarmIndex |  alarm                        |    
		|--------------------------------------------------|    
		|__________________________________________________|  

		 _____________________________________________
		| nlmLogTable                                 |    
		|---------------------------------------------|    
		| nlmLogIndex |  alarm                        |    
		|---------------------------------------------|    
		|      1      | acmeWidgetTemperatureCritical |
		|      2      | bgpBackwardTransition         |
		|      3      | acmeWidgetTemperatureNormal   |
		|_____________________________________________|  

7. Security Considerations

   There are no management objects defined in this MIB that have a MAX-
   ACCESS clause of read-write and/or read-create.  So, if this MIB is
   implemented correctly, then there is no risk that an intruder can
   alter or create any management objects of this MIB via direct SNMP
   SET operations.

8. References
  	[1] Stewart, B, "Notification Log MIB, draft 12, October 1999

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 24 Jul 2000 10:27:25 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> From: "Sharon Chisholm" <[email-masked]>
> To: [email-masked]
> Subject: Distributed Active Alarms
> Date: Mon, 17 Jul 2000 14:25:05 -0400
...
> Please let me know what you think.
...

I'll add this to the agenda for the Pittsburgh meeting.
Will an internet draft be appearing?  

Since there are patent claims (could you supply the number
or a URL for the patent?), please review the requirements of
RFC 2026, in particular:

    clause 4.1.2 first paragraph
    clause 10.3.2 (A)
    clause 10.4

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 24 Jul 2000 22:29:41 -0400

hi

The patent which may apply to this was recently filed, so we don't
have a number yet.  I just have the information that I sent you and Steve
before.  I can clean up the document as per "Guidelines to Authors of
Internet-Drafts"
and send it to [email-masked] to get a tangible file name to
refer to in the web page to comply with RFC 2026 section 10.3.2 (c).  Or did
you want something sooner?

Newby question 1:  Is all that is required in the internet draft pertaining
to intellectual property a statement of compliance with RFC 2026, section
10?  

Newby question 2:  Is this an individual submission internet draft or a
working
group internet draft?  My goal would be for it to be a working group
internet
draft, but somehow I feel I would be skipping a step if I called it that.

I think I missed the deadline for getting something sent out before the
meeting
next week, but I will try and get something sent out this week anyways.

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]]
Sent: Monday, July 24, 2000 1:27 PM
To: [email-masked]
Subject: Re: Distributed Active Alarms

Hi -

> Message-ID:
<[email-masked]>
...
...

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 25 Jul 2000 07:34:02 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> To: Randy Presuhn <[email-masked]>, [email-masked]
> Cc: [email-masked]
> Subject: RE: Distributed Active Alarms
> Date: Mon, 24 Jul 2000 22:29:41 -0400
...
> have a number yet.  I just have the information that I sent you and =
> Steve
> refer to in the web page to comply with RFC 2026 section 10.3.2 (c).  =
> Or did

Just add the appropriate boilerplate and IPR statements.

> Newby question 1:  Is all that is required in the internet draft =
> pertaining
> to intellectual property a statement of compliance with RFC 2026, =
> section
> 10? =20

RFC 2026 contains some magical incantations that should be
included, along with instructions for their use.  If your
intention is to request that the working group consider
making this a work item, it would probably make sense to
use the boilerplate for "standards track" documents.

> draft, but somehow I feel I would be skipping a step if I called it =
> that.

At this time, it would be an individual submission.  If there
is sufficient interest on this mailing list and at the
Pittsburgh meeting, and if our area director approves, we
could add this as a work item to our charter.  At that point,
a draft-ietf-disman-* name would be appropriate.

...

The deadline for I-D submission has passed.  We can still
talk about whether there is interest in taking this on as a
new work item.  I'd like to hear what other participants in
the WG think.

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 25 Jul 2000 07:42:34 -0700 (PDT)

Hi -

Here's a message from Steve Coya for the disman list.
I've added him to the "posters" file so he can now post to
this list without having to subscribe.

> Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
> 	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA18465;
> 	Tue, 25 Jul 2000 05:14:59 -0700 (PDT)
> Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
> 	by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e6PCFR402831;
> 	Tue, 25 Jul 2000 07:15:27 -0500 (CDT)
> Received: from scoya.cnri.reston.va.us (scoya.cnri.reston.va.us [10.27.5.106])
> 	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22010;
> 	Tue, 25 Jul 2000 08:15:38 -0400 (EDT)
> Date: Tue, 25 Jul 2000 08:14:23 -0400 (Eastern Daylight Time)
> From: Steve Coya <[email-masked]>
> Reply-To: Steve Coya <[email-masked]>
> To: Sharon Chisholm <[email-masked]>
> cc: Randy Presuhn <[email-masked]>, [email-masked]
> In-Reply-To: <[email-masked]>
> Message-ID: <[email-masked]>
> X-X-Sender: [email-masked]
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA22010
> Content-Transfer-Encoding: 8bit
> X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id FAA18466
> 
> 
> Hi Sharon,
> 
> On Mon, 24 Jul 2000, Sharon Chisholm wrote:
> 
> >>hi
> >>
> >>The patent which may apply to this was recently filed, so we don't have
> >>a number yet.  I just have the information that I sent you and Steve
> >>Internet-Drafts"  and send it to [email-masked] to get a
> >>tangible file name to refer to in the web page to comply with RFC 2026
> >>section 10.3.2 (c).  Or did you want something sooner? 
> 
> I'm assuming the above question is for Randy :-)
> 
> >>Newby question 1:  Is all that is required in the internet draft
> >>pertaining to intellectual property a statement of compliance with RFC
> >>2026, section 10? 
> 
> Yes, though much depends on which option you choose, and your intention
> with respect to changes and/or derrivitive works.
> 
> Assuming you wish to retain change control, including contact information
> for licensing (assuming you intend to offer this) in the I-D is a good
> idea.
> 
> 
> >>working group internet draft?  My goal would be for it to be a working
> >>group internet draft, but somehow I feel I would be skipping a step if I
> >>called it that. 
> 
> You did just right. It is up to the WG Chair as to whether your document
> is to be a WG Internet-Draft. And it is up to each WG chair to make this
> decision based on the IPR statements (some will not allow any submissions
> encumbered, others will). Of course, if you chose option three, the point
> is moot.
> 
> 
> >>meeting next week, but I will try and get something sent out this week
> >>anyways. 
> 
> You did miss thre deadline. Anything you send prior to July 31 will NOT be
> processed as an Internet-Draft, but you certainly may resubmit beginning
> July 31 (though announcements will not be made until August 7).
> 
> 
> 
> 
> >>Sharon
> >>