[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: disman MIB Followup on gmpls-alarm-spec-
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 <lberger@movaz.com>
To: Tom Petch <nwnetworks@dial.pipex.com>; Randy Presuhn
<randy_presuhn@mindspring.com>
Cc: Wijnen, Bert (Bert) <bwijnen@lucent.com>; ccamp@ops.ietf.org
<ccamp@ops.ietf.org>
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) <bwijnen@lucent.com>
>>To: Brungard, Deborah A, ALABS <dbrungard@att.com>; Wijnen, Bert (Bert)
>><bwijnen@lucent.com>; Adrian Farrel <adrian@olddog.co.uk>; Lou Berger
>><lberger@movaz.com>
>>Cc: ccamp@ops.ietf.org <ccamp@ops.ietf.org>
>>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:dbrungard@att.com]
>> >> Sent: dinsdag 18 november 2003 23:06
>> >> To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger
>> >> Cc: ccamp@ops.ietf.org
>> >> 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:bwijnen@lucent.com]
>> >> Sent: Tuesday, November 11, 2003 11:46 AM
>> >> To: Adrian Farrel; Lou Berger
>> >> Cc: ccamp@ops.ietf.org
>> >> 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:adrian@olddog.co.uk]
>> >> > Sent: dinsdag 11 november 2003 17:28
>> >> > To: Lou Berger
>> >> > Cc: ccamp@ops.ietf.org
>> >> > 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)
>> >> >
>> >> >
>> >>
>> >
>