Subject: Re: disman MIB Followup on gmpls-alarm-spec-

From: "Tom Petch" <[email-masked]>
Date: Fri, 6 Feb 2004 20:58:11 -0000

Yes, my concerns are allayed.

One point you may be aware of is that there has been a discussion on the
Disman list as a result of IESG concerns over how new values would be added
to the list.  IANA (naturally) with the range 1 to 1023 aiming to be
aligned with any new alarms from ITU and 1025 upwards for ones from any
other source.  So you are referring to a moving target, in IANA rather than
in an RFC.  (This is of course not new but I have yet to see an elegant
approach to it).  You might want to add some words to this effect.

(You will find the new text, not yet in an I-D, in a thread
[Disman] Propose Resolution to iesg-1 and iesg-5 (take 3)
Date: 22 January 2004 20:45
of which the last entry contains

>The following is the proposed resolution to IESG-1 and IESG-5
>
>In the description for IanaItuProbableCause, replace the description
>
>"ITU probable cause values. Duplicate values defined in X.733
>           are appended with X733 to ensure uniqueness. Probable cause
>           value 0 is reserved for special purposes.
>
>           The Internet Assigned Number Authority (IANA) is responsible
>           for the assignment of all Internet numbers, including
>           various SNMP-related numbers, and specifically, new
>           IANAItuProbableCause values. Values of
>           IANAItuProbableCause less than 1024 are reserved for causes
>           that correspond to ITU probable cause. IANAItuProbableCause
>           of 0 is reserved for special purposes and therefore cannot
>           be assigned. See http://www.iana.org"
>
>With
>
>"          ITU-T probable cause values. Duplicate values defined in X.733
>           are appended with X733 to ensure syntactic uniqueness. Probable
cause
>           value 0 is reserved for special purposes.
>
>           The Internet Assigned Number Authority (IANA) is responsible
>           for the assignment of the enumerations in this TC.
>           IANAItuProbableCause value of 0 is reserved for special
>           purposes and MUST NOT be assigned.
>
>           Values of IANAItuProbableCause in the range 1 to 1023 are
reserved
>           for causes that correspond to ITU-T probable cause.
>
>           All other requests for new causes will be handled on a
first-come,
>           first served basis and will be assigned enumeration values
starting
>           with 1025.
>
>           Request should  come in the form of well-formed SMI [RFC2578]
>           for enumeration names that are unique and sufficiently
descriptive.
>
>           While some effort will be taken to ensure that new probable
causes
>           do not conceptually duplicate existing probable causes it is
>           acknowledged that the existence of conceptual duplicates in the
>           starting probable cause list is an known industry reality.
>
>           To aid IANA in the administration of probable cause names and
values,
>           the OPS Area Director will appoint one or more experts to help
review
>           requests.
>           See http://www.iana.org
(end of extract from Disman mailing list)

Tom Petch

-----Original Message-----
From: Lou Berger <[email-masked]>
To: Tom Petch <[email-masked]>; Randy Presuhn
<[email-masked]>
Cc: Wijnen, Bert (Bert) <[email-masked]>; [email-masked]
<[email-masked]>
Date: 30 January 2004 15:01
Subject: disman MIB Followup on gmpls-alarm-spec-

>Tom, (Randy)
>
>         Thank you for providing this input.  What we're looking for is a
>reference that provides enumerated values for alarms.  The ITU specs that
>we found all provide text strings, which is what we're trying to avoid.
It
>seems that the disman MIB provides exactly what we're looking for.
>
>Please let us know if our intended use of the values defined in the MIB
>makes sense from your (disman WG's) perspective, or if you recommend an
>alternate approach.
>
>Thank you,
>Lou
>
>PS The text in the new rev (submitted today) of the draft reads:
>[from: http://labn.net/docs/draft-berger-ccamp-gmpls-alarm-spec-01.txt]
>3.1.3. Error Codes and Values
>
>    The Error Codes and Values used in ALARM_SPEC objects are the same as
>    those used in ERROR_SPEC objects.  New Error Code values for use with
>    both ERROR_SPEC and ALARM_SPEC objects may be assigned to support
>    alarm types defined by other standards.
>
>    In this document we define one new Error Code.  The Error Code uses
>    the value TBA (by IANA) and is referred to as "Alarms".  The values
>    used in the Error Values field are the same as the values used for
>    IANAItuProbableCause in the Alarm MIB [ALARM-MIB].
>
>The error values field is carried in an object with the format:
>[from: rfc3473]
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |            Length             | Class-Num (6) | C-Type (3)    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     IPv4 Error Node Address                   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Flags     |   Error Code  |          Error Value          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    ~                              TLVs                             ~
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>At 10:20 AM 11/19/2003, Tom Petch wrote:
>>FYI
>>
>>
>>As a member of the disman WG, I have followed the development of the
alarm
>>mib,
>>currently draft-ietf-disman-alarm-mib-15.txt, over some years and this
has
>>included formal liaison with SG4 and some contact with SG15 over such
>>issues as
>>who owns the code points and who can define them.  SG4 have expressed
>>satisfaction with the way in which the liaison with disman WG has worked
>>(as on
>>the IETF web site).
>>
>>But
>>
>>1) not knowing the working procedures of the ITU, I don't know if the
>>agreement
>>with disman extends to other IETF WG - the wording suggests not to me.
>>
>>2) the alarm mib is currently under debate between authors and WG chair
with a
>>list of some 80 issues being resolved; the most difficult to resolve
>>appear IMO
>>to be the ones relating to the existence of the ITU alarm table as an
>>augmentation of the basic disman alarm table (and perhaps IMHO the lack
of
>>suitable features in SMIv2).  The alarm mib is complex, not one I would
expect
>>people to be able to dip into and readily extract a part thereof.
>>
>>3) I have lost track of the start of this thread and just what it was
that
>>this,
>>ccamp, WG
>>wanted to include in what (and my Acrobat viewer renders the text of the
>>bullet
>>points in AlarmSpec as black blobs of varying size:-(!  But whatever it
is, I
>>suggest you contact the
>>disman chair, randy presuhn, to clarify the niceties of any interaction
>>with the
>>output of disman, whatever form that finally takes.  It may be that
M.3100
>>related material should be in a common MIB module and not included in the
>>alarm
>>mib because of issues of future updates and cross references from
multiple
>>WGs..
>>
>>I think this is known as cross-functional review:-)
>>
>>Tom Petch
>>
>>
>>-----Original Message-----
>>From: Wijnen, Bert (Bert) <[email-masked]>
>>To: Brungard, Deborah A, ALABS <[email-masked]>; Wijnen, Bert (Bert)
>><[email-masked]>; Adrian Farrel <[email-masked]>; Lou Berger
>><[email-masked]>
>>Cc: [email-masked] <[email-masked]>
>>Date: 18 November 2003 23:10
>>Subject: RE: Taking to the
list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
>>
>>
>> >the disman mib has enumerations I believe!
>> >
>> >Thanks,
>> >Bert
>> >
>> >> -----Original Message-----
>> >> From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
>> >> Sent: dinsdag 18 november 2003 23:06
>> >> To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger
>> >> Cc: [email-masked]
>> >> Subject: RE: Taking to the
>> >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
>> >>
>> >>
>> >> Thanks Bert.
>> >>
>> >> M.3100 provides the generic information model, X.733 and
>> >> X.736 define OSI generics pointing to X.721, and X.721
>> >> provides abstract syntax. We were looking for an enumeration
>> >> to use vs. needing to support abstract syntax strings in
>> >> signaling. Any suggestions are welcome.
>> >> Deborah
>> >>
>> >> -----Original Message-----
>> >> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
>> >> Sent: Tuesday, November 11, 2003 11:46 AM
>> >> To: Adrian Farrel; Lou Berger
>> >> Cc: [email-masked]
>> >> Subject: RE: Taking to the
>> >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
>> >>
>> >>
>> >> Things to potentially look at:
>> >>
>> >>   draft-ietf-disman-alarm-mib-15.txt
>> >>
>> >>   [M.3100]    ITU Recommendation M.3100, "Generic Network Information
>> >>               Model", 1995
>> >>
>> >>   [X.733]     ITU Recommendation X.733, "Information Technology -
Open
>> >>               Systems Interconnection - System Management: Alarm
>> >>               Reporting Function", 1992
>> >>
>> >>   [X.736]     ITU Recommendation X.736, "Information Technology -
Open
>> >>               Systems Interconnection - System Management: Security
>> >>               Alarm Reporting Function", 1992
>> >>
>> >> Thanks,
>> >> Bert
>> >>
>> >> > -----Original Message-----
>> >> > From: Adrian Farrel [mailto:[email-masked]]
>> >> > Sent: dinsdag 11 november 2003 17:28
>> >> > To: Lou Berger
>> >> > Cc: [email-masked]
>> >> > Subject: Re: Taking to the
>> >> > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
>> >> >
>> >> >
>> >> > Lou,
>> >> >
>> >> > I believe the alarm reference was M.3100.
>> >> >
>> >> > Can someone confirm?
>> >> >
>> >> > Adrian
>> >> >
>> >> >
>> >> > > In the morning's meeting the AD's asked to bring the
>> >> proposed Alarm
>> >> > > communication extension to "the list".  For today's
>> >> > presentation see:
>> >> > > http://www.labn.net/docs/AlarmSpec00.pdf
>> >> > >
>> >> > > I believe the issues to be discussed are:
>> >> > > 1) Is there general interest in this work?
>> >> > > 2) Should the usage of new TLVs in Error_Spec be permitted?
>> >> > >          (We think there's some value, particularly with string
>> >> > >           and timestamp)
>> >> > > 3) Are there good references for alarm code points?
>> >> > >
>> >> > > Thank,
>> >> > > Lou (and co-authors)
>> >> >
>> >> >
>> >>
>> >
>