Subject: RE: FW: Probable Cause

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 14 Apr 2002 12:33:01 +0200

Is this just me that sort of wrries when I see

> Some more duplication cases in ITU-IANA-ALARM-TC:
>  

To me it is either a set of ITU controled TCs, or a set
of IANA controled TCs. How is this going to work out
if both organisations need to stay in sync on this?

Has anybody checked with ITU that they are happy to be
restricted to 255 code points? Can we get that in a
statement from them (possibly from SG 4?)?

Do we have arranged for ITU to check and sign-off on the
values we currently have in this document?

Maybe I am just worrying too much... I am pretty busy with 
other stuff, so I have not followed all the emails/postings
all that closely.

Bert

---

From: "Dave Sidor" <[email-masked]>
Date: Mon, 22 Apr 2002 12:09:55 -0400

Bert, Randy, Randy,

In Bert's email below he raised an issue that SG 4 addressed at its
meeting that concluded on Friday. The SG 4 input is presented below
Bert's email and also attached as a Word document. I have also copied
this email to the IETF email address for communication statements from
other organizations.

Dave Sidor
Chairman, ITU-T SG 4

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

> other stuff, so I have not followed all the emails/postings

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

ITU - Telecommunication Standardization Sector	

Temporary Document 86 (Rev.1) (PLEN)

STUDY GROUP 4

Geneva, 8 - 19 April 2002

QUESTIONS:	19/4

SOURCE:	ITU-T Study Group 4

TITLE:	Additional input regarding the use of  M.3100 probable causes for
the ITU Alarm MIB
_____________

COMMUNICATION STATEMENT

TO:	IETF disman WG

APPROVAL:	Agreed to at STUDY GROUP 4 MEETING 

FOR:	ACTIOND

EADLINE:	January 1,  2003

CONTACT :	
Dave Matthews
Acting Rapporteur, Question 19/4
AT&T
USA	
Tel :	+1 732 420 1613
Email: [email-masked]

At the ITU-T Study Group 4 meeting in April 2002, we have examined
version 6 of the IETF Alarm MIB focusing of course on those aspects
related to the ITU-T SG 4 Recommendations and offer the following
comments:

- We have examined version 6 of the Alarm MIB
(draft-ietf-disman-alarm-mib-06) and noted your incorporation of the
M.3100 probable causes semantics. We thank you for that action in
response to our July 2001 communication statement.

- If you recall, in our July 2001 communication statement, we suggested
the need for some extensibility mechanism and also we have been made
aware that probable cause semantics other than that from the ITU-T are
being reviewed, presumably for possible inclusion. We have discussed the
possible impact of the latter and have come to the following
conclusions:

1) While we value the identical number assignments for the M.3100
probable causes, regardless of the number assignments, we believe the
ITU-T semantics are the most important aspect to retain.

2) Though M.3100 is currently using less than 256 probable causes, there
is a likelihood that additional values will be needed.  (The M.3100
syntax of ASN.1 INTEGER is, of course, able to support larger values.)

3) We have noted in section 5.2 that you have specified an
IANAItuProbableCause textual convention apparently dedicated to the
ITU-T probable causes and support that separation from any other
probable cause asssignments. To ensure that separation, we recommend
that the first paragraph of section 5.2 be replaced with the following
text:

"Values of IANAItuProbableCause can only be given out if they correspond
to ITU probable causes semantics present in ITU-T Recommendations and
are agreed to by the disman working group."

We believe this text reflects the fact that this textual convention is
limited to representing the ITU semantics while at the same time
identifying the IETF as the owner of the alarm MIB. Other textual
conventions would be presumably required to define the semantics and
number assignments of other probable causes. 

4) To assist the reader of the current specification, we recommend the
replacement of the DESCRIPTION text with the following text: " ITU
probable cause values for alarms are currently assigned as per
M.3100-1995 (1-254), X.733-1992 (256-287), and X.736-1992 (288-303)." 

5) We also note that code 158 (reinitialized) is missing.

We would be grateful if you would keep us informed of your progress on
this topic.