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

"Sharon Chisholm" <[email protected]> Fri, 13 Feb 2004 15:23:02 -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.

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