[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: disman MIB Followup on gmpls-alarm-spec-



TO me this looks fine

Thanks,
Bert 

> -----Original Message-----
> From: Lou Berger [mailto:lberger@movaz.com]
> Sent: vrijdag 30 januari 2004 16:01
> To: Tom Petch; Randy Presuhn
> Cc: Wijnen, Bert (Bert); ccamp@ops.ietf.org
> 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)
> > >> >
> > >> >
> > >>
> > >
>