Re: ForCES Protocol Implementation Issues

"Joel M. Halpern" <joel@stevecrocker.com> Sat, 15 September 2007 16:20 UTC

Message-Id: <SAT.15.SEP.2007.122037.0400.>
Date: Sat, 15 Sep 2007 12:20:37 -0400
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: ForCES Protocol Implementation Issues
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"

If we want the FEState to be the way that a cE administratively
disables and FE, then we would need to make a larger change.  When I
drafted the FEState component, my expectation was that
administratively disable would reflect non-Forces interaction, such
as a "disable" CLI command.
Given that the other two values (operationally disabled and
operationally enabled) can not be used as the value in a set
operation, I think that to change this we would have to create two
separate variables, a read-write admin-status and a read-only
operation-status.  (I thought we had that at one point and decided
not to keep it, but I could be confused.)

Yours,
Joel

At 10:35 AM 9/13/2007, Jamal Hadi Salim wrote:
>On Thu, 2007-13-09 at 00:50 -0400, B. J. Kang wrote:
>
> > I have already seen both the article "Protocol" and "Model",but i
> don't see any
> > more information about this(FEO Adminup). I have read them and tried to
> > implement them about several mouths, may I lose some thing?
>
>FEO LFB belongs to the model; the text in the protocol mentions it in
>passing and not in greater detail. Sorry, I should have been more
>specific in my response to you:
>Section 8.2 of version 7 of the model talks about FEO LFB attribute
>FEState which is of type FEStatusValue that contains a possibility of
>setting Admin to disable or operational status to on/off. "Admin up" is
>intended to mean configuring that attribute to Admin enabled.
>The discussion as i recall was to not have adminEnable enumeration
>because operational enable in this case implied Admin enabled.
>Looking at the model draft i saw that FEState is defined as read-only.
>
>So you actually bring two issues that need to be fixed:
>1)Since the model is still being edited, I think we need to change that
>control to be read-write instead of read-only. Does that make sense
>Joel?
>2) Since this has caused some headache, to avoid the next person having
>the same issue, the protocol needs to be very explicit
>
>I have tried to open tracker issues but it seems down;
>Joel, Avri - i guess the only way to keep track of this is write it down
>somewhere?
>
>In any case, B. J. Kang, thanks for bringing these issues up.
>
>cheers,
>jamal