RE: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is sema ntically wrong

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: entmib@ietf.org
>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:dperkins@dsperkins.com] 
>Sent: Thursday, February 12, 2004 3:51 PM
>To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org
>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: 'entmib@ietf.org'
>>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:rt+entity-state@rt.psg.com]
>>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 [kzm@cisco.com]
>>
>>"
>>>   '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
>Entmib@ietf.org
>https://www1.ietf.org/mailman/listinfo/entmib
>
>_______________________________________________
>Entmib mailing list
>Entmib@ietf.org
>https://www1.ietf.org/mailman/listinfo/entmib 

_______________________________________________
Entmib mailing list
Entmib@ietf.org
https://www1.ietf.org/mailman/listinfo/entmib