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

From: Muly Ilan <[email-masked]>
Date: Tue, 7 May 2002 14:59:07 +0200

Hi,

In my opinion the inconsistentValue error is appropriate in case of conflict
with existing request.

The APS standard defines a clear and strict priority for requests/states. If
an operator issues an external request (e.g. manual switch) while the
current state is of higher priority (e.g. SD) then he tries to violate the
defined order and an inconsistentValue should be returned.
This is not a question of resources available or not. Both the working and
protection line are always considered to be available, just operating
according to priority rules. Look at the opposite example - the working line
is manually switched to protection, now an SD on the protection line would
cause an automatic switch back and at some time later an SF on working line
would again cause a switchover. Thus, the resources are always there.

Muly Ilan

-----Original Message-----
From: Joan Cucchiara [mailto:[email-masked]]
Sent: Tuesday, May 07, 2002 2:54 AM
To: Mike Thatcher
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-atommib-sonetaps-mib-07.txt

Mike Thatcher wrote:
> 
> Joan Cucchiara wrote:
> >
> > Mike Thatcher wrote:
> >
> >>Joan Cucchiara wrote:
> >>
> ...
> >>>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.
> >
> >
> > 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

---

From: Joan Cucchiara <[email-masked]>
Date: Tue, 07 May 2002 12:29:41 -0400

Okay, I think I am understanding this
now and inconsistentValue is reasonable error here. 
Thanks for the explanation. Would like to see this
documented in the MIB, if possible.

  -thanks, 
   Joan