Subject: References to X.733 in Draft Documents.

From: Rajesh Lalan <[email-masked]>
Date: Tue, 06 Mar 2001 15:18:10 -0600

Disman Group,

   I have one comment about references to X.733 documents in
the recently published drafts from this working group.

   a)    "SnmpAlarm MIB" and "Alarm MIB" documents have
referenced X.733 for Textual-Conventions for
          snmpITUAlarmPercSeverity and snmpItuAlarmTrendInd
enumerations.
           X.721 should be the correct reference for these
enumerations along with other X.700 documents.

   b)   There is almost no reason to change the order of
enumerations  found in X.721. If it is necessary to
          bump the enumeration from zero based to one based,
that could be ok.  But there is no reason to
          resequnce enumeratons in IETF documents.  We are
not adding any value by doing this.

        example 1:
        IETF document
               snmpItuAlarmTrendInd  is defined as   {
moreSevere(1),  noChange(2),  lessSevere(3)  }
        ITU X.721:
                  TrendIndication :== Enumerated
{lessSevere(0),noChange(1),moreSevere(2)}

         example 2:             PerceivedSeverity
enumeration.
         IETF document:
           SYNTAX INTEGER { cleared(1), indeterminate(2),
critical(3), major(4),
                                                 minor(5),
warning(6) }
         ITU-T X.721:
              PerceivedSeverity :==  ENUMERATED {
interdeterminate(0),

critical(1), major(2), minor(3), warning(4), cleared(5) }

          Almost all X.700 documents refer to X.721 for
these enumerations.
          Bottom line is,  please look at X.721,  cite it
and try not to scramble the enumerations unless justified.

Thanks
Raj.

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 7 Mar 2001 10:37:17 -0500

X.721 is available at
ftp://47.234.32.16/itu_to_ietf/SG4/
along with other ITU-T documents, such as X.733 and M.3100.

By the way for information, X.733 is the requirement recommendation for the
alarm reporting function. It describes what information should be contained
in a alarm report (alarm notification), including probable cause (aka alarm
type). It defines a list of commonly used probable causes (used in telecom).
X.721 maps this list of probable causes into Object Identifier (OID - not
enumeration) for use in CMIP. So it is globally unique and can be extended
under registration control. M.3100 has a similar but more extensive list of
probable causes and is defined using local integers within the TMN
Application Context. It is also for use in CMIP. 

Regards,
Kam

-----Original Message-----
From: Rajesh Lalan [mailto:[email-masked]]
Sent: Tuesday, March 06, 2001 7:11 PM
To: Ayers, Mike; [email-masked]
Subject: Re: References to X.733 in Draft Documents.

"Ayers, Mike" wrote:

> > From: Rajesh Lalan [mailto:[email-masked]]
> >
>         We currently do not have access to X.721.

Sorry, I cannot provide you a copy of X.721, but anyone working with
X.733 and referencing it, should easily be able to access X.721.

> Even if we did, I would
> not be comfortable making a requirement of matching enumerations with it.
> The reason is that we would also need to leave space open in case
> modifications are made to the existing model.

I agree this a good enough reason. ITU has a process for that as well
(X.208)
but I would have to research it some more..., some other time.

> Our requirement is that the
> model be mappable with the ITU model, not be the same as it, and I think
I'd
> be uncomfortable raising the stakes.
>
>         With all that said, I think that it would be a good idea for the
> numeric values in the final model to align with the ITU numeric values
where
> possible.

Exactly what I am trying to say. The IETF model should be mappable, but
there is no reason to make this mapping more difficult than necessary.
If we have a good reason to make the IETF model different, that is OK,
we should not make the mapping  inconsistant because we did not
research the ITU model thoroughly.

I say this because some other snmpITUAlarm textual-conventions are NOT
resequenced,  example snmpITUProbCause,  This one is just bumped up
by one (one based as opposed to zero based) and a few new causes
were added at the end of the list.

The stuff  IETF puts out is generally taken as gospel in some parts.
We should'nt treat it lightly.

- Raj.

> /|/|ike