RE: RE: [psg.com #307] AutoReply: 'notSupported' is sema ntically wrong
"David T. Perkins" <[email protected]> Fri, 13 Feb 2004 12:42:33 -0800
| Newsgroups | gmane.ietf.entmib |
|---|---|
| Message-ID | <[email protected]> |
HI, No, no, no - get rid of the "not reportable" terminology! At 03:23 PM 2/13/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-307. The issue >will be considered closed pending the proposed edit being done. > >Replace the enumeration 'notSupported' with 'unavailable' in each of >the TCs and any references within the text. > >For each of the (TC, object definition) pairs, move the following sort >of text from the object definition to the textual convention: > >"A value >of 'unavailable' means that this resource is unable to report [this] >state." > >Modifications include > section 3.1, pp 3 > section 3.4 > TC AdminState > TC OperState > TC UsageState > TC AlarmStatus > TC StandbyStatus > Object entStateAdmin > Object entStateOper > Object entStateUsage > Object entStateAlarm > Object entStateStandby > >Sharon > >-----Original Message----- >From: Chisholm, Sharon [CAR:0S00:EXCH] >Sent: Thursday, February 12, 2004 3:59 PM >To: [email protected] >Subject: RE: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is sema >ntically wrong > > >Hi > >Well, if we are to pick from the three, I think "unavailable" aligns best >with resolving this issue. > >Sharon > >-----Original Message----- >From: David T. Perkins [mailto:[email protected]] >Sent: Thursday, February 12, 2004 3:51 PM >To: Chisholm, Sharon [CAR:0S00:EXCH]; [email protected] >Subject: Re: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is >semantically wrong > > >HI, > >For me, the term "notReportable" is worse than "notSupported". The terms >"notSupported", "unknown" and "unavailable" are used in MIB modules indicate >an appropriate value cannot be obtained by the access or instrumentation >code. > >Mods: >section 3.1, pp 3 >section 3.4 >TC AdminState >TC OperState >TC UsageState >TC AlarmStatus >TC StandbyStatus >Object entStateAdmin >Object entStateOper >Object entStateUsage >Object entStateAlarm >Object entStateStandby > > > >At 01:53 PM 2/11/2004 -0500, Sharon Chisholm wrote: >>Hi >> >>That last bit should read >> >>""A value >>of 'notReportable' means that this resource is unable to report [this] >>state." >> >>Sharon >> >>-----Original Message----- >>From: Chisholm, Sharon [CAR:0S00:EXCH] >>Sent: Wednesday, February 11, 2004 1:51 PM >>To: '[email protected]' >>Subject: FW: [psg.com #307] AutoReply: 'notSupported' is semantically >>wrong >> >> >>The following is the proposed resolution to entstate-307. The issue >>will be considered closed pending the proposed edit being done. >> >>Replace the enumeration 'notSupported' with 'notReportable' in each of >>the TCs and any references within the text. >> >>For each of the (TC, object definition) pairs, move the following sort >>of text from the object definition to the textual convention: >> >>"A value >>of 'notApplicable' means that this resource is unable to report [this] >>state." >> >>Sharon >> >>-----Original Message----- >>From: entity-state [mailto:[email protected]] >>Sent: Tuesday, January 13, 2004 2:50 AM >>To: Chisholm, Sharon [CAR:0S00:EXCH] >>Subject: [psg.com #307] AutoReply: 'notSupported' is semantically wrong >> >><clip> >> >>----------------------------------------------------------------------- >>-- >>Keith McCloghrie [[email protected]] >> >>" >>> 'notSupported' is semantically wrong, because a compliant >>implementation >>> obviously supports the MIB, but it can return 'notSupported' for >>> every object in the MIB. Presumably, the intended semantics is that >>> the agent would return the right value if only it knew the right >>value; >>> i.e., 'unknown' is the desired semantics. Also, why is each >>definition >>> of 'notSupported' defined in an object's DESCRIPTION, not in the >>TC's >>> DESCRIPTION ?" >/david t. perkins > > >_______________________________________________ >Entmib mailing list >[email protected] >https://www1.ietf.org/mailman/listinfo/entmib > >_______________________________________________ >Entmib mailing list >[email protected] >https://www1.ietf.org/mailman/listinfo/entmib