Re: [forces] Avoiding need to issue a draft every time WAS(Re: FEO events

I think that there are several issues combined here.

We already have mechanisms so that anyone can define LFBs.  And that 
includes new subclasses of existing LFBs.  Note that he information as 
to what LFB classes and subclasses an FE supports is easily 
discoverable, by design.

There is the question of whether event mechanism should be more easily 
extended than a new subclass.  I have trouble seeing how we could do 
that, since in many instances it will require different code in the FE 
to generate new events.

Then there is the question of changes to the FEO (or FEPO).  For 
itneroperability, those have to be very stable.  In this case, for 
example, if your CE needs those events, you can only work with FEs that 
have been upgraded to generate those events from the FEO.   If we allow 
random changes to the FEO, the probability of interoperability between 
independent implementations is very low.  So while I am sympathetic, I 
am reluctant to go down a path the makes interoperability harder.

Yours,
Joel

On 11/20/14, 9:57 AM, Jamal Hadi Salim wrote:
> As i was saying in the FEO email - the idea that i have to send
> draft updates for every component or event is becoming
> burdensome. I have quiet a few but dont have the energy to
> publish them given the process.
> In the last few months we have implemented a few LFBs based
> on open source datapath code. In all cases, there is a continous
> stream of new LFB components initially with trickles down afterwards
> to what seems to be stability. "Stability" in some cases means we
> have one new component added every 2-3 months.
> IOW, *churn is a way of life*.
> Clearly our current model is going to be burdensome with heavy
> standardization process (some of it bordering on the ridiculous).
>
> The fact that i have to suffer through this for some time now
> because of the pace at which opensource is moving and recent
> comments from  Julian Reschke on why we dont even need to revise
> versions re-ignited this issue for me.
>
> Two approaches come to mind for ForCES:
> a) publish a base LFB document - we then have a living document
> somewhere which gets updates. There may be no point in coming back
> to the IETF after this.
> b) build discoverabillty in. Something along the same line of get properties
> semantics we have but that returns all the supported components for example.
>
> At least our implementation is adding #b but it is proprietary. I just wanted
> to bounce this off the list first and see what at least the usual suspects feel.
>
> Thoughts?
>
> cheers,
> jamal
>
> On Thu, Nov 20, 2014 at 9:31 AM, Jamal Hadi Salim <hadi@mojatatu.com> wrote:
>> I have a use case for a control app needing to know when
>> an LFB class instance is created or destroyed (without polling
>> for changes). I have added (and currently coding) the attached patch
>> to FEObject LFB.
>>
>>   Is there any objection to this approach?
>>
>> It is becoming painful that i have to submit a draft every time we make
>> such a small change. This generally speaks to the issue of "standards"
>> and IETF in general than anything else. I will make another posting
>> so this thread doesnt go on a tangent.
>>
>> cheers,
>> jamal
>
> _______________________________________________
> forces mailing list
> forces@ietf.org
> https://www.ietf.org/mailman/listinfo/forces
>