Subject: RE: [seamoby] Final Seamoby Agenda

From: Phillip Neumiller <[email-masked]>
Date: Fri, 27 Jul 2001 10:50:43 -0400

Hello Hamid,

Framework is another one of those "overloaded" words to be
consider dangerous.  Typically, I think of things like the
"don't call us, we'll call you" paradigm of software
development, i.e. somebody has identified the useful design
patterns for a particular problem domain and has provided
a framework, upon which you can build your own applications.
Microsoft's Foundation Classes (MFC) come to mind, and there
are lots of other commercial OO frameworks.  

I have seen the word "framework" abused in the embedded real
time community to mean something like the main event loop 
logic.  

Your use of the term *seems* to be the one I love to hate,
i.e. some kind of monolothic all knowing scroll that tells
you what all the problems you are going to encounter are
going to be.  We have been down this path MANY times in
SeaMoby and each time we have come to the same "cul de sac".

The IETF ain't a good place to do architectural work!!!!

So, what I am saying, is though a framework may be useful
for you in your company's development and documentation
efforts, it is not likely to fly very far in the IETF.
At least that has been my experience so far...

Thanks,

Phil

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Friday, July 27, 2001 10:26 AM
> To: Hamid Syed
> Cc: Pat Calhoun; seamoby
> Subject: Re: [seamoby] Final Seamoby Agenda
> 
> 
> On Fri, Jul 27, 2001 at 10:23:49AM -0700, Hamid Syed wrote:
> > Re: [seamoby] Final Seamoby AgendaPat,
> > 
> > I think a framework definition is very important to capture 
> the various aspects of ct that can enable a seamless 
> handover. We had some very good disicussions on the list 
> regarding proactive/reactive ct modes , the triggers to 
> initiate each of them and a handover candidate discovery 
> mechanism is under considerations too. All these bits and 
> pieces are taken, for the time being as separate items but in 
> reality they are inter-related. The ordering and timing of 
> various network events together with handoff candidate 
> discovery and context transfer between ARs should follow some 
> specified patterns. 
> > 
> 
> ok, let me try. So, a framework kind of puts everything in 
> perspective?
> How is it better than just defining a protocol? Does it 
> describe how it is
> actually used? You mention triggers, but there is separate 
> effort under
> way to define triggers, and as you know, they are very 
> technology specific.
> Speaking of, CT will behave differently based on the mobility 
> management
> protocol used. 
> 
> > Seamoby definitely needs a CT framework that can capture 
> the relationship between all the pieces we are discussing 
> today. Otherwise, defining a protocol to carry some 
> information from one point to the other is not that trivial 
> and would not help improving the performance of handover.
> 
> So what are all the pieces? You mean all of the Seamoby 
> protocol(s) and
> perhaps even mobility management protocols as well? If this 
> is what you
> mean, then I would tend to agree. Some guidance on how to take these
> protocols and implement them in such a way that it actually 
> works, would
> be beneficial.
> 
> PatC
>

---

From: "Hamid Syed" <[email-masked]>
Date: Fri, 27 Jul 2001 11:05:35 -0700

RE: [seamoby] Final Seamoby AgendaPhil,

I can point you to number of IETF WGs that did define frameowrks and then worked on the protocol design. This is not true to say that frameworks does not fly at the IETF. 

-Hamid
  ----- Original Message ----- 
  From: Phillip Neumiller 
  To: 'Pat Calhoun' ; Syed, Hamid [WDLN2:AN22:EXCH] 
  Cc: seamoby 
  Sent: Friday, July 27, 2001 7:50 AM
  Subject: RE: [seamoby] Final Seamoby Agenda

  Hello Hamid, 

  Thanks, 

  Phil