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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 6 May 2002 17:21:05 +0200

This is a WG-chair decision. But I think adding some
clarifying text should not require a new WG Last Call.
If you just quickly post the peices fo text being clarified,
then anyone who sees an issue can speak up right away,
otherwise they always have another chance to react at IETF 
Last Call (as far as I know that still needs to happen).

Bert 
Speaking as just a mib-person.

> -----Original Message-----
> From: Mike Thatcher [mailto:[email-masked]]
> Sent: Monday, May 06, 2002 5:11 PM
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-atommib-sonetaps-mib-07.txt
> 
> 
> 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?
> 
> Wijnen, Bert (Bert) wrote:
> > 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: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 7 May 2002 13:10:55 +0200

This discussion explains why it is good to add
to the description clause the "agreed upon" error 
to be returned.

Bert 

> From: Joan Cucchiara [mailto:[email-masked]]
> Sent: Tuesday, May 07, 2002 2:54 AM
> To: Mike Thatcher
> Mike Thatcher wrote:
> > > Mike Thatcher wrote:
> > ...
> > >>Again according to 1905 4.2.5, Inconsistent value error 
> is the only appropriate
> > >>response.
> > >
> > >
> > > Based on the description of the object (quoted above), 
> would think that
> > > this
> > > error should be resourceUnavailable...if the resource 
> weren't being
> > > taken up by the equal or higher priority request, then 
> the set should
> > > probably succeed, right?  Why do you think this is 
> inconsistentValue?
> > >
> > > Could you explain a little more please?
> > >
> > 
> > I was looking at the new request being inconsistent with 
> the existing request. I
> > don't see the resource as unavailable, since it is 
> available and is being
> > operated on, just the command couldn't execute because of 
> conflict with existing
> > request.  If you think the resourceUnavailable is a better 
> return code, I can
> > live with that.
> 
> Hi Mike,
> 
> I can see your point, but do think resourceUnavailable is more
> meaningful error
> in this situation.
> 
>   thanks, Joan
> 
> > 
> > miket
>