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

"Sharon Chisholm" <[email protected]> Sun, 15 Feb 2004 16:39:28 -0500
Newsgroups gmane.ietf.entmib
Message-ID <[email protected]>
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:[email protected]] 
Sent: Friday, February 13, 2004 3:43 PM
To: Chisholm, Sharon [CAR:0S00:EXCH]; [email protected]
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: [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