Subject: RE: I-D ACTION:draft-ietf-atommib-sonetaps-mib-07.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 6 May 2002 15:20:30 +0200

Mike and others,

I think it may be helpful to readers if the explanations
given below are indeed also in the DESCRIPTION clause of the
TC. I have noticed many times that people are not absolutely
clear on the proper error to return, and documenting it
(possibly with a ptr to the text that explains why) is
good I think.

Bert 

> -----Original Message-----
> From: Mike Thatcher [mailto:[email-masked]]
> Sent: Monday, May 06, 2002 11:46 AM
> To: [email-masked]
> Cc: Joan Cucchiara
> Subject: Re: I-D ACTION:draft-ietf-atommib-sonetaps-mib-07.txt
> 
> 
> Joan Cucchiara wrote:
> > Hello,
> > 
> > Could the ApsSwitchCommand and ApsControlCommand TCs 
> > specify what error codes the Agent is to return 
> > under the various conditions?
> > 
> > For example, the noCmd(1), says this value may not
> > be written, so if it was written would
> > the agent return a wrongValue error?
> > 
> According to RFC 1905, 4.2.5, wrongValue is the appropriate response.
> 
> > Also, if manualSwitchWorkToProtect(6) is already
> > switch to the protection channel, would the agent
> > return an inconsistentValue error?
> > 
> 
> Yes, since the description states that this command can only 
> be applied to a 
> working channel.
> 
> > Also, in the description of the apsCommandSwitch object,
> > it states "...If the APS switch command cannot be executed
> > because an equal or higher priority request is in effect, an
> > error is returned."  What error would this be?
> > 
> 
> Again according to 1905 4.2.5, Inconsistent value error is 
> the only appropriate 
> response.
> 
> > If this could be clarified in the TCs and objects in the
> > MIB that would be appreciated.
> > 
> 
> I don't believe a clarification is required. RFC 1905 4.2.5 
> is clear about error 
> returns for set processing.
> 
> miket
> 
>

---

From: Mike Thatcher <[email-masked]>
Date: Mon, 06 May 2002 08:11:01 -0700

I agree that it is helpfull to spell out errors.  However, turning another rev 
of the draft means restarting the clock on last call.  We've been trying to get 
this through last call for quite a while when there are no technical issues but 
only clarifications.  Can we issue a rev without restarting the clock?