Working TT docs for IETF UCP WG

Paul Zawada <zawada@ncsa.uiuc.edu> Mon, 02 November 1992 20:46 UTC

Date: Mon, 2 Nov 92 14:42:01 CST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Paul Zawada <zawada@ncsa.uiuc.edu>
Message-Id: <9211022042.AA05555@bliga.ncsa.uiuc.edu>
To: ucp@nic.near.net
Subject: Working TT docs for IETF UCP WG

Hi Folks...

Well, it is getting close to the IETF meeting, so Kaj Tesink and I have
both been working on our TT documents. Kaj is currently traveling, so
I am sending mail for the two of us.

You may recall Kaj and I were working on two separate documents. Kaj's
task was to develop a spec for passing TT's in RFC822 mail. My task was
to continue to refine the ASN.1 description of inter-NOC trouble tickets.
While we hoped to combine the two before the next meeting, I am not so sure
that my schedule will allow a very refined combination of the two. (I must
appologize to Kaj, since his part was ready in August... I simply have not
had much extra time to devote to these specs.)

*** What this email includes ****

1. Kaj Tesink's e-mail trouble ticket spec. Note: this is only a
"first pass" I anticipate much input from the UCP group.

2. The latest and greatest of the ASN.1 description we've tossed
around at the UCP meetings. I've encorporated many of the
suggestions made at the last meeting.

3. A "sample" trouble ticket (hopefully) based on the ASN.1
description.

********************************

Caveats: Kaj wanted me to mention some unresolved points at the offset:

- He uses many keywords in the message body. Should some of these
keywords be placed in the mail header? Personally, I feel that we
should keep the TT distinct from the mail header. This keeps
the TT independent from the mail platform it is running on.

- He uses ip addresses. He also has specific entries for ping and SNMP.
Should we be protocol specific? I don't think so.. In fact, the
ASN.1 description does not go into any detail whatsoever in the
description of the problem. It currently stands as free text so
the person making the ticket can put in anything he likes; ping
or SNMP reachability, route problems, number of photons lost, etc...

- He mentions NOC subscription and unsolicited notifications, although
no formal procedure is written yet. How do we want to handle
distribution of tickets to NOCs not involved in the problem?

- And timestamps... We discussed this in some detail at the last
meeting, although I cannot not recall a clear "winner." Kaj
suggests the 822 timestamp, while I prefer the GMT output returned
by the UNIX "date -u" command. I beleive GMT was the more favored
format but I can't recall... Can we settle this one last time?

Some things to mention about the ASN.1 description...

- Recall that we're using the SMI used for SNMP. (I can't recall
what RFC that is off the top of my head.) We need a slightly
different definition for the ACCESS attribute. Since we are not
communicating with an agent, read-only and read-write need different
meanings. I propose that read-only mean that an entry cannot be
changed once it is created. A read-write attribute would then be
defined as one which could be altered at a later time, such as the
number of NSCs in the NSC list, etc.

- While I have tried to write my sample TT to closely follow the ASN.1
descritption, I am not an ASN.1 guru. I need help verifying the ASN.1
descritption to make sure it actually defines a trouble ticket as I
depict below. Most errors will be that I incorrectly wrote the ASN.1
description, not the ticket!

- I have not double checked the "STATUS" attribute of most variables
in the description, so some may be wrong...

I think the biggest thing we need to address right now is what documents
are really needed. Personally, looking at the following texts, I think
we ought to develop two documents out of the work done thus far.

1. A formal description of the TT presumably passed along a mail
a mail message. (Right now we assume 822-mail, would this
fit into MIME as well?) This would include methods used to
pass a TT from one NSC to another.

2. A description of a system system which tickets could be collected
and redistributed. Perhaps we should include the notion of public
and private tickets in the first document. The redistribution
system would only redistribute public tickets.

I feel that it is important to establish 1 and get that done first.
We can worry about #2 later.

In the next week I hope to come up with some sort of document to combine
the TT mail spec with the ASN.1 spec. I will send that out as soon as
possible. I do not expect an immediate response on any of the documents
I send out today. This mail message is more of a "heads-up" so people
can be prepared for the meeting. So, PLEASE READ THESE DOCS BEFORE THE
MEETING! (However, I will gladly accept any constructive criticism or
comments in the meantime...)

Hopefully you will be hearing from me again soon...

--zawada

-----------------------------------ENCLOSURES-----------------------

1. DRAFT of RFC822 submission of trouble tickets.........

=====================================================================

D R A F T

Network Working Group Kaj Tesink
Request For Comments: Bellcore

July 1992

Support of the NOC Trouble Submission Facility by
RFC822 based message exchange

Status of This Memo

This memo provides information for the Internet community. It does
not specify an Internet standard. Distribution of this memo is
unlimited.

Abstract

This memo suggests a straight-forward approach towards supporting
RFC-NOCTSF
via RFC 822 based message exchange.

Table of Contents

1. Background
2. Overview
3. Notationa Conventions
4. Lexical Analysis of Messages
5. Mapping of the RFC-NOCTSF to RFC822 messages
5.1. Trouble Ticket Request syntax
5.1.1. Use of the Subject and Message body fields
5.1.2. TTLocalOriginatorId
5.1.3. TTComment
5.1.4. TTLocalProblemCode
5.1.5. TTSNMPObserved
5.1.6. TTSNMPExpected
5.1.7. TTPing
5.2. Trouble Ticket Reply syntax
5.2.1. Use of the Subject and Message body fields
5.2.2. TTLocalOriginatorId
5.2.3. TTComment
5.2.4. TTLocalProblemCode
5.2.5. TTSNMPObserved
5.2.6. TTPing
5.2.7. TTRepair expected by
5.3. Trouble Ticket Notification syntax
5.4. Trouble Ticket Status Request syntax
5.5. Trouble Ticket Status Confirmation syntax
5.6. Trouble Ticket Append Request syntax
5.7. Trouble Ticket Append Confirmation syntax
5.8. Trouble Ticket Cancel Request syntax
5.9. Trouble Ticket Cancel Confirmation syntax
6. Acknowledgements
7. References

1. Background

RFC-NOCTSF describes the functions that need to be supported for NOC
Trouble Ticket handling. The Trouble Reporting may be used by both
end-users and by NOCs.

The functions in RFC-NOCTSF can be efficiently supported vis a number
of access protocols, where each protocol can leverage its particular
strength.

This document describes how RFC-NOCTSF can be supported via RFC822-based
message exchange. The strength of this protocol is:
- Ubiquity
- Simplicity
- It is well tailored to some of the needs of the NOC TSF, e.g., it
allows for verbose and possibly imprecise trouble descriptions, and at
the same time it can also be structured to allow for automatic
parsing of precise problem descriptions.

This document describes the use of basic RFC822 messages only, relying
on ASCII message bodies. The use of other message body types as for
example explained in RFC-MIME is not addressed in this memo.

In some cases, it might be desirable to ensure private message exchange,
for example by the use of PEM described in RFC-PEM. The use of PEM is
not addressed in this memo.

2. Overview

The NOC TSF is accessable via a mailbox. This mailbox shall be used
as follows:
- Incoming messages shall be parsed for known keywords and problem
descriptions as described in this document. In addition, NOCs may add
keywords/problem descriptions for automatic parsing as relevant for
their particular environment. Messages that are succesfully parsed on
keywords/problem descriptions will be processed by the NOC trouble
resolution and tracking system and responded to with message templates
as described in this memo.
- Messages for which automatic inclusion in the NOC trouble resolution
and tracking system is not possible will be parsed by a NOC employee.
The employee will then provide appropriate input to the NOC trouble
resolution and tracking system and responded to the message with
message templates as described in this memo. RFC-NOCTSF describes a
number of functions for information exchange between a NOC TSF and
its users (which may be other NOCs):

User --> NOC NOC --> User
1. Trouble Ticket Request Trouble Ticket Reply
2. Trouble Ticket Notification
3. Trouble Ticket Status Request Trouble Ticket Status
Confirmation
4. Trouble Ticket Append Request Trouble Ticket Append
Confirmation
5. Trouble Ticket Cancel Request Trouble Ticket Cancel
Confirmation

In addition, NOCs may want to support an on-line subscription procedure:

a. NOC Subscription Request NOC Subscription Confirmation
b. NOC Unsubscription Request NOC Unsubscription Confirmation

Subscription implies that this user will receive relevant NOC TSF messages.

The procedures in this memo rely on a loose coupling of NOC procedures:
- Common NOC TSF access procedures are maintained (this memo), but internal

NOC procedures for trouble resolution and tracking can be quite different

(compare for example an internet NOC with a telco NOC).
- Trouble Ticket referrals will be required under certain circumstances.
While the original NOC where the trouble was reported will maintain
"ownership" of the trouble with regard to reporting back to the user
that flagged the trouble, the trouble may have to be handed off to
other NOC(s) for appropriate trouble resolution. This memo relies on a
procedure where Trouble Ticket Identifiers are local to a NOC; no global
administration of TT Ids is assumed or necessary.

NOCs as well as other network users may have a number of network management
tools for trouble identification at their disposal. Examples include
ping()
and a variety of SNMP based tools. This memo includes the use of these
tools
as a possible trouble reporting technique.

3. Notational Conventions

This specification uses the same notational conventions as are used in
RFC 822.

4. Lexical Analysis of Messages

The rules for the lexical analysis as defined in RFC 822 apply. In
addition,
this memo defines structure in the message body. The lexical analysis rules

are extended to the message body as defined in this memo.

5. Mapping of the RFC-NOCTSF to RFC822 messages

This clause defines the messages for access with NOC Trouble Submission
Facilities. An important key to the correct use of these procedures is
the use of the "Subject" line in RFC822 messages.

5.1. Trouble Ticket Request syntax

5.1.1. Use of the Subject and Message body fields

The Subject field shall be used as follows:

Subject field = "TTId : Non-assigned TTRequest" / "TTId :" TTId "TTRequest"

The Message body shall be present and shall consist of any combination
of the following fields:

message body=
/ "TTOriginatorTTId" ":" TTId
/ "TTComment" ":" *text
/ "TTLocalProblemCode ":" problem-list
/ "TTSNMPObserved" ":" snmptext
/ "TTSNMPExpected" ":" snmptext
/ "TTPing" ":" pingtext

5.1.2. TTOriginatorId

This field, which may be present in the message body can be used for
local reference purposes. This field must be present when received
from another NOC. A number of TTId instances may be present.
The sequence of their appearance determines the following:
- Stapling of different TTs into a single new TT. For example, two open
TTs X and Y that are determined to have the same cause may result
into a new TT Z. Messages referring to Z would use:
"TTOriginatorTTId : X
Y".
- The referral sequence that the trouble report has gone through (e.g.,
between NOCs). For example, the referral of the previous TT Z to
another NOC would, assuming acceptance by that NOC result in:
"TTOriginatorTTId : Z
X
Y".
The assuming NOC will use its own TTId, for example K. Referral
to a third NOC would result in:
"TTOriginatorTTId : K
Z
X
Y".

This implies that the TTIds must be globally unique. This is achieved
by prepending locally defined TTIds (unique for a local NOC) with the
identification of the host that represents the TT service of that NOC.
The identifier will be of the form of a Network Address. The types of
Network Address that are used are: IP Address.

TTId =
/ TTId
/ network-address TTIdValue
network-address = IP address
TTIdValue = *text

5.1.3. TTComment

This field, which may be present in the message body can be used for a
textual description of the observed problem.

5.1.4. TTLocalProblemCode

This field, which may be present in the message body can be used for
identifying a problem code that is unique for the local NOC. Note
that in case of TT referrals, a number of instances of this field may
be present. The sequence of their appearance determines the referral
sequence that the trouble report has gone through. This implies that
the problem codes must be globally unique. This is achieved by prepending
locally defined problem codes (unique for a local NOC) with the
identification of the host that represents the TT service of that NOC. The
identifier will
be of the form of a Network Address. The types of Network Address that
are used are: IP Address.

problem-list = network-address ProblemCodeValue
network-address = IP address
ProblemCodeValue = *text

5.1.5. TTSNMPObserved

This field, which may be present in the message body can be used for
identifying a problem observed via the use of SNMP. Multiple instances
of this field may be present, for example

snmptext = object-name "=" objectvalue
objectname =
/ NetworkAddress OBJECT IDENTIFIER Object Instance
/ NetworkAddress OBJECT DESCRIPTOR Object Instance
object value = *text

For proper use of the components of objectname, see RFC1155.

For example suppose a network user obeserves a linkDown from SNMP Agent
192.99.99.199 (for example an agent monitoring a router), this user might
complain to the NOC with:

TTSNMPObserved:192.99.99.199.ifOperStatus.14=2
TTSNMPExpected:192.99.99.199.ifOperStatus.14=1

with ifOperStatus the object in question on the router and 14 the
particular link instance that is down. The value 2 indicates down,
and 1 indicates up (see RFC1213). This information is likely supplied
by a local SNMP tool of that user.

5.1.6. TTSNMPExpected

This field, which may only be present if the TTSNMPObserved field is
present, can be used to elaborate on a problem noted via TTSNMPObserved.

For the syntax of this field see TTSNMPObserved.

5.1.7. TTPing

5.2. Trouble Ticket Reply syntax

The Trouble Ticket Reply is used in response to a previously issued
Trouble Ticket Request.

5.2.1. Use of the Subject and Message body fields

The Subject field shall be used as follows:

Subject field = "TTId : Non-assigned" / "TTId :" TTId "TTStatus :"
TTstatus

TTId shall be used as follows:

TTId = network-address TTIdValue
network-address = IP address
TTIdValue = *text

TTstatus shall be used as follows:

TTstatus = "Open" / "Closed" / "Stapled to :" TTId

The value "Open" corresponds to a situation where a NOC TSF has identified
a problem, relevant for NOC TSF users, that requires some time to resolve.
The value "Closed" corresponds to a situation where a previously identified

problem has been resolved.
The value "Stapled to :" implies a situation where a previously identified
problem is determined to be part of another identified problem relevant for

the NOC TSF user. Inquiries to the status of the problem resolution can
refer
to either TTId.

The Message body may be present and shall consist of any combination of the
following fields:

message body=
/ "TTOriginatorTTId" ":" TTId
/ "TTComment" ":" *text
/ "TTLocalProblemCode ":" problem-list
/ "TTSNMPObserved" ":" snmptext
/ "TTPing" ":" pingtext
/ "TTRepair expected by" ":" data&time

5.2.2. TTOriginatorId

This field, which shall be present and shall be used as described
in 5.1.2.

5.2.3. TTComment

This field, which may be present in the message body can be used for a
textual description of the observed problem.

5.2.4. TTLocalProblemCode

This field, which may be present in the message body can be used for
identifying a problem code that is unique for the local NOC.
The use of this field is as defined in the TTRequest.

5.2.5. TTSNMPObserved

This field, which may be present in the message body can be used for
identifying a problem observed via the use of SNMP. Multiple instances
of this field may be present. The use of this field is as defined in the
TTRequest.

5.2.6. TTPing

5.2.7. TTRepair expected by

This field, which may be present in the message body, gives an indication
of the time when the problem is expected to be solved. This field may
have the same format as the "Date" field in the message header.

5.3. Trouble Ticket Notification syntax

The Trouble Ticket Notification is used to flag a problem to NOC TSF users
observed by the NOC. It can also be used to notify a status change of
previously opened Trouble Tickets.

The Subject field shall be used as defined for the Trouble Ticket Reply.

The message body may be present. Its use shall be the same as the message
body of the Trouble Ticket Reply.

5.4. Trouble Ticket Status Request syntax

The trouble Ticket Status Request can be used by a user of the NOC TSF to
request the status of a previously opened Trouble Ticket.

The Subject field shall be used as follows:

Subject field = "TTId :" TTId "TTStatus :"

The use of the TTId shall be as defined in the Trouble Ticket Reply

No message body need to be present. The message body may be ignored
by the NOC.

5.5. Trouble Ticket Status Confirmation syntax

Trouble Ticket Status Indication is used by the NOC TSF to reply to a
previously submitted Trouble Ticket Status Request by a NOC TSF user.

The syntax of the Trouble Ticket Status Indication shall follow the
syntax of the Trouble Ticket Notification. The TTId in the Subject
field matches the value of the TTId in the Trouble Ticket Status Request.

5.6. Trouble Ticket Append Request syntax

The Trouble Ticket Append Request can be used by a NOC TSF user to
request to append additional information to a previously opened
Trouble Ticket.

The Subject field shall be used as follows:

Subject field = "TTId :" TTId "TTAppend :"

The use of the TTId shall be as defined in the Trouble Ticket Reply

The message body shall follow the same syntax as the message body in
the Trouble Ticket Request.

5.7. Trouble Ticket Append Confirmation syntax

The Trouble Ticket Append Confirmation shall be used by a NOC TSF user
to reply to a previously submitted user request to append information
to a Trouble Ticket.

The Subject field shall be used as follows:

Subject field = "TTId :" TTId "TTAppend Confirmation"

The use of the TTId shall be as defined in the Trouble Ticket Reply

The message body shall follow the same syntax as the message body in the
Trouble Ticket Reply.

5.8. Trouble Ticket Cancel Request syntax

The Trouble Ticket Cancel Request can be used by a NOC TSF user to request
cancellation of a previously opened Trouble Ticket.

The Subject field shall be used as follows:

Subject field = "TTId :" TTId "TTCancel"

The use of the TTId shall be as defined in the Trouble Ticket Reply

No message body need to be present. The message body may be ignored by
the NOC.

5.9. Trouble Ticket Cancel Confirmation syntax

The Trouble Ticket Cancel Confirmation shall be used by a NOC TSF in
reply to a previously submitted Trouble Ticket Cancel Request by a
NOC TSF user to confirm cancellation of a previously opened Trouble
Ticket.

The Subject field shall be used as follows:

Subject field = "TTId :" TTId "TTCancel"

The use of the TTId shall be as defined in the Trouble Ticket Reply

The message body shall follow the same syntax as the message body in
the Trouble Ticket Reply.

No message body need to be present.

6. Acknowledgements

This document was developed in the IETF User Connectivity Problems
Working Group.

7. References

RFC-NOCTSF Functional Spec for an On-line Trouble Submission
Facility - Kaj Tesink, Dale Johnson,
Draft 3/18/92, San Diego

RFC822 Standard for the format of ARPA Internet text messages - David
Crocker, August 13, 1982

RFC1155 Structure and Identification of Management Information for
TCP/IP-based Internets - Marshall Rose, Keith McClogrie, May 1990

RFC1213 Management Information Base for Network Management of
TCP/IP-based internets - Marshall Rose, Keith McClogrie, March 1991

Addresses of the authors:

Kaj Tesink
Bellcore
331 Newman Spring Rd.
RedBank, NJ 07701
Bellcore
Tel. (908) 758-5254
Fax.(908) 758-4196
Email kaj@cc.bellcore.com

0------------0--------------0-------------0-------------0-----------0
Kaj Tesink
pmail Bellcore vmail (908) 758-5254
331 Newman Springs Rd. faxmail (908) 758-4196
Red Bank, NJ 07701 email kaj@cc.bellcore.com

=====================================================================
2. ASN.1 description of inter-NOC TT messages

$Header: /home/net/wsnet/zawada/z/UCP/RCS/exchange.asn,v 1.5 1992/10/30 21:38:11 zawada Exp $

info OBJECT IDENTIFIER ::= { exchange 1 }
nsc OBJECT IDENTIFIER ::= { exchange 2 }
people OBJECT IDENTIFIER ::= { exchange 3 }
contact OBJECT IDENTIFIER ::= { exchange 4 }
notify OBJECT IDENTIFIER ::= { exchange 5 }
notes OBJECT IDENTIFIER ::= { exchange 6 }

-- The info group

infoEntry OBJECT-TYPE
SYNTAX InfoEntry
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The info entry provides specific information on the
nature (and possibly solution) of the problem."
::= { info 1 }

InfoEntry ::= SEQUENCE {
infoProbDesc DisplayString,
infoSolnDesc DisplayString,
infoProbLoc DisplayString,
infoStartDate DisplayString,
infoEndDate DisplayString,
infoOpenDate DisplayString,
infoCloseDate DisplayString,
infoTicketNum DisplayString
}

infoProbDesc OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A text summary of the problem."
::= { infoEntry 1 }

infoSolnDesc OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..255))
ACCESS read-only
STATUS optional
DESCRIPTION
"A text summary of the solution to the problem."
::= { infoEntry 2 }

infoProbLoc OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..80))
ACCESS read-only
STATUS optional
DESCRIPTION
"The location of the problem."
::= { infoEntry 3 }

infoStartDate OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..30))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The date the problem started."
::= { infoEntry 4 }

infoEndDate OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..30))
ACCESS read-only
STATUS optional
DESCRIPTION
"The date the problem ended."
::= { infoEntry 5 }

infoOpenDate OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..30))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The date the ticket was opened"
::= { infoEntry 6 }

infoCloseDate OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..30))
ACCESS read-only
STATUS optional
DESCRIPTION
"The date the ticket was closed."
::= { infoEntry 7 }

infoTicketNum OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..30))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A trouble ticket identifier normally consisting
of a number assigned by the originating NSC
preceded by the NSC's unique prefix."
::= { infoEntry 8 }

-- The nsc group

nscNum OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The total number of entries in the NSC list."
::= { nsc 1 }

nscList OBJECT-TYPE
SYNTAX SEQUENCE OF NscEntry
ACCESS read-write
STATUS mandatory
DESCRIPTION
"List of NSCs that have handled the problem. It
is assumed the the first NSC in the list is the
originating NSC."
::= { nsc 2 }

nscEntry OBJECT-TYPE
SYNTAX NscEntry
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Each entry contains an index and a name of an
NSC who handled the problem."

NscEntry ::= SEQUENCE {
nscIndex Counter,
nscId DisplayString,
nscEmail DisplayString,
nscDate DisplayString }

nscIndex OBJECT-TYPE
SYNTAX Counter
ACCESS read-write
STATUS mandatory
DESCRIPTION
"An index number for the particular NSC in this entry.
Index number 1 is assumed to be the originator."
::= { nscEntry 1 }

nscId OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..20))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The name of the NSC for this entry."
::= { nscEntry 2 }

nscEmail OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..127))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"NSC email address for handling trouble tickets."
::= { nscEntry 3 }

nscDate OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..30))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Timestamp when this NSC first started handling this ticket"
::= { nscEntry 4 }

-- The people group

peopleNum OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The total number of people in the people list."
::= { people 1 }

peopleTable OBJECT-TYPE
SYNTAX SEQUENCE OF PeopleEntry
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A list of persons associated with a ticket."
::= { people 2 }

peopleEntry OBJECT-TYPE
SYNTAX PeopleEntry
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Information (email, phone, etc.) needed to get in
touch with the person."
::= { peopleTable 1 }

PeopleEntry ::= SEQUENCE {
peopleIndex Counter,
peopleName DisplayString,
peopleEmail DisplayString,
peoplePhone DisplayString,
peopleFax DisplayString,
peopleOther DisplayString
}

peopleIndex OBJECT-TYPE
SYNTAX Counter
ACCESS read-write
STATUS mandatory
DESCRIPTION
"person number."
::= { peopleEntry 1 }

peopleName OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..63))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Name of person."
::= { peopleEntry 2 }

peopleEmail OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..127))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Email address of person."
::= { peopleEntry 3 }

peoplePhone OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..31))
ACCESS read-write
STATUS optional
DESCRIPTION
"Phone number of person."
::= { peopleEntry 4 }

peopleFax OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..31))
ACCESS read-write
STATUS optional
DESCRIPTION
"Fax number of person."
::= { peopleEntry 5 }

peoplePager OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..31))
ACCESS read-write
STATUS optional
DESCRIPTION
"Pager number of person."
::= { peopleEntry 6 }

peopleOther OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..80))
ACCESS read-write
STATUS optional
DESCRIPTION
"Any miscellaneous information about the person."
::= { peopleEntry 7 }

peoplePrefer OBJECT-TYPE
SYNTAX INTEGER {
email(1),
telephone(2),
fax(3),
pager(4)
any(255)
}
ACCESS read-write
STATUS optional
DESCRIPTION
"Preferred method of commumnication."
::= { peopleEntry 8 }

-- The contact group

contactNum OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The total number of available contacts."
::= { contact 1 }

contactTable OBJECT-TYPE
SYNTAX SEQUENCE OF ContactEntry
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A list of persons who can be contacted about
the problem. These persons shall also be listed
in the people group"
::= { contact 2 }

contactEntry OBJECT-TYPE
SYNTAX contactEntry
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Information concerning notification."
::= { contactTable 1 }

contactEntry ::= SEQUENCE {
contactIndex Counter,
contactName DisplayString,
contactOther DisplayString
}

contactIndex OBJECT-TYPE
SYNTAX Counter
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Contact index number."
::= { contactEntry 1 }

contactName OBJECT-TYPE
SYNTAX Counter
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Contact entry name. This name must appear in the
people list."
::= { contactEntry 2 }

contactOther OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..80))
ACCESS read-write
STATUS optional
DESCRIPTION
"Any miscellaneous information about the contact."
::= { contactEntry 3 }

-- The notify group

notifyNum OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The total number of entities to notify when problem is
solved."
::= { notify 1 }

notifyTable OBJECT-TYPE
SYNTAX SEQUENCE OF NotifyEntry
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A list of persons or NSCs which wish to be contacted
when the problem is resolved or significant progress
is made in solving the problem."
::= { notify 2 }

notifyEntry OBJECT-TYPE
SYNTAX NotifyEntry
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Information concerning notification."
::= { notifyTable 1 }

NotifyEntry ::= SEQUENCE {
notifyIndex Counter,
notifyName DisplayString,
notifyType INTEGER,
notifyOther DisplayString
}

notifyIndex OBJECT-TYPE
SYNTAX Counter
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Notify index number."
::= { notifyEntry 1 }

notifyName OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..63))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Name of entity to be contacted. If notify type
is NSC, the name shall be found in the NSC list.
If notify type is person, the name shall be found
in the people list."
::= { notifyEntry 2 }

notifyType OBJECT-TYPE
SYNTAX INTEGER {
NSC(1),
person(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Type of entity to be contacted."
::= { notifyEntry 3 }

notifyOther OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..80))
ACCESS read-write
STATUS optional
DESCRIPTION
"Any miscellaneous information about the contact."
::= { notifyEntry 4 }

-- The notes group

notesNum OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The total number of notes in the notes list."
::= { notes 1 }

notesTable OBJECT-TYPE
SYNTAX SEQUENCE OF NotesEntry
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A list of possible useful comments that can be added
by entities dealing with the problem."
::= { notes 2 }

notesEntry OBJECT-TYPE
SYNTAX NotesEntry
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Indiviual notes."
::= { notesTable 1 }

NotesEntry ::= SEQUENCE {
notesIndex Counter,
notesDate DisplayString,
notesAuthor DisplayString,
notesNumLines DisplayString,
notesText DisplayString }

notesIndex OBJECT-TYPE
SYNTAX Counter
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Note index number."
::= { notesEntry 1 }

notesDate OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..30))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Date of message."
::= { notesEntry 2 }

notesAuthor OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..15))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Author of message. This person should appear in
the people list."
::= { notesEntry 3 }

notesNumLines OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The number of 80 character lines in the message."
::= { notesEntry 4 }

notesText OBJECT-TYPE
SYNTAX SEQUENCE of NotesText
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Text body of message."
::= { notesEntry 5 }

NotesText ::= SEQUENCE {
textIndex Counter,
textLine DisplayString }

textIndex OBJECT-TYPE
SYNTAX Counter
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Text line index number."
::= { notesText 1 }

textLine OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..80))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A single line of the text body"
::= { notesText 2 }

END -- Exchange Definitions --

=====================================================================
3. Sample Trouble Ticket based on the above ASN.1 description

infoProbDesc: Net 199.2.3.4 is unreach able from widget.com, a imaginary.net customer
infoSolnDesc: Replaced bad Cable
infoProbLoc: avn.net's Timbuktoo POP
infoStartDate: Fri Oct 30 17:07:45 GMT 1992
infoEndDate: Fri Oct 30 18:10:28 GMT 1992
infoOpenDate: Fri Oct 30 17:32:01 GMT 1992
infoCloseDate: Fri Oct 30 18:15:16 GMT 1992
infoTicketNum: INI1234

nscNum: 2
nscId.1: INI (Imaginary Networks Incoporated)
nscEmail.1: trouble@imaginary.net
nscDate.1: Fri Oct 30 17:32:01 GMT 1992
nscId.2: AVN (Advanced Vapor Networks)
nscEmail.2: tt@avn.net
nscDate.2: Fri Oct 30 18:01:01 GMT 1992

peopleNum: 2
peopleName.1: Joe Engineer
peopleEmail.1: joee@imaginary.net
peoplePhone.1: 1-800-555-1234
peopleFax.1: 1-800-555-4321
peoplePager.1: 1-800-555-1111
peoplePrefer.1: 1
peopleName.2: Will U Shuddup
peopleEmail.2: will@avn.net
peoplePhone.2: 1-800-555-6788
peopleFax.2: 1-800-555-6742
peoplePrefer.2: 2
peopleName.3: John Enduser
peopleEmail.3: je@widget.com
peoplePrefer.3: 1

contactNum: 2
contactName.1: Joe Engineer
contactOther.1: Point of contact for imaginary.net
contactName.2: Will U Shuddup
contactOther.2: Working on problem at avn.net

notifyNum: 2
notifyName.1: INI
notifyType.1: 1
notifyName.2: John Enduser
notifyType.2: 2
notifyOther.2: This is the end user who first noticed the problem;

notesNum: 3
notesDate.1: Fri Oct 30 17:32:10 GMT 1992
notesAuthor.1: Joe Engineer
notesNumLines.1: 2
notesEntry.1.textline.1: User called complaining that he could not reach 199.2.3.4, blort.bliga.edu
notesEntry.1.textline.2: Could not ping host from foo.imaginary.net and traceroute stops at gate.avn.net
notesDate.2: Fri Oct 30 18:07:28 GMT 1992
notesAuthor.2: Will U Shuddup
notesNumLines.2: 2
notesEntry.2.textline.1: Gateway router does not seem to be talking to bliga.edu
notesEntry.2.textline.2: Currently investigating
notesDate.3: Fri Oct 30 18:13:55 GMT 1992
notesAuthor.3: Will U Shuddup
notesNumLines.3: 1
notesEntry.3.textline.1: Replaced bad cable between gateway router and CSU/DSU. Connectivity restored.

--
Paul J. Zawada KB9FMN
NCSAnet Network Engineer zawada@ncsa.uiuc.edu
National Center for Supercomputing Applications ..!pur-ee!zawada

Working TT docs for IETF UCP WG Paul Zawada