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

The following is the proposed resolution to entstate-307. The issue will be
considered closed pending the proposed edit being done.

[Note, we've gotten rid of the enumeration 'notReportable' in favour of more
standard ones. The descriptive text, as far as I can see, aligns with what
we all seem to be agreeing this enumeration means]

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: David T. Perkins [mailto:dperkins@dsperkins.com] 
Sent: Friday, February 13, 2004 3:43 PM
To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org
Subject: 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