Subject: Re: [seamoby] Final Seamoby Agenda

From: James Kempf <[email-masked]>
Date: Mon, 23 Jul 2001 15:33:23 -0700 (PDT)

Attached is a description of the MORE BOF and an agenda. We would like
to use the bulk of the time to discuss mobile wireless service providers'
requirements for IETF protocols, though there are also a few presentations
on specific items. The requirements will be folded into an informational
RFC and circulated to the mobility related WGs. Paul Reynolds and I
will be co-chairing. Many thanx to Pat and Allison for helping get
this scheduled. 

		jak
For many years, individuals involved in ISPs have been an important component
of IETF, as they have brought experience and requirements to the task
of developing protocols for the Internet. Until recently, most ISPs
were involved in providing service through standard wired networks.
With the growth of the wireless Internet, the technology and business
of mobile operators are becoming more like that of an ISP and less like
that of a telephone company. Mobile operators have traditionally not had as 
close a relationship with the IETF. In this BOF, we would like to discuss 
the requirements from wireless ISPs presented in the recently released 
Internet Draft draft-reynolds-mobile-isp-requirements-00.txt. Many 
individuals are now coming to the IETF with requirements and suggestions 
for mobile networking protocol development. This BOF is an opportunity for
those who will have to deploy and offer Internet
services on wireless networks to present what they think the
requirements for the protocols to support those services should be,
and for equipment vendors, software developers, academic researchers, and
others involved in engineering and development of mobile networking
protocols to engage in a discussion about wireless ISP
requirements. The discussion in the BOF and on the MORE mailing list
will be folded into the draft, and the draft will be circulated
among interested working groups for development of IETF concensus,
before publishing as an Informational RFC.
Introduction/Agenda Bashing (James Kempf, [email-masked]) - 5 min.

Discussion of issues from the mailing   
list regarding the draft (Paul Reynolds, [email-masked]) - 5 min.

Application protocol requirements for
the mobile Internet (John  Waclawsky, [email-masked] ) - 5 min.

Classification of requirements to working - 5 min.
groups (or other topic) (Atsushi Takeshita, [email-masked]) 

Micro/macrocellular interaction requirements - 5 min.
(Rich Robinson, [email-masked])

Dynamic service negotiation requirements
(Jyh-Cheng Chen, [email-masked]) - 10 min.

Discussion - 25 min.

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Tue, 24 Jul 2001 17:56:56 -0400

James,

	Could you please tell me the time and the place when this BOF is
held? I would like to
attend. Thanks.

Sharif.

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Monday, July 23, 2001 6:33 PM
To: [email-masked]
Subject: Re: [seamoby] Final Seamoby Agenda

		jak

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 27 Jul 2001 11:07:30 -0400

Yes, Phil, bottom up design works so very well ;^|

Gary

> From: Phillip Neumiller [mailto:[email-masked]]
> Sent: July 27, 2001 10:51
> To: 'Pat Calhoun'; Syed, Hamid [WDLN2:AN22:EXCH]
> Cc: seamoby
> Subject: RE: [seamoby] Final Seamoby Agenda
> 
> 
> 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
> 
> > From: Pat Calhoun [mailto:[email-masked]]
> > Sent: Friday, July 27, 2001 10:26 AM
> > To: Hamid Syed
> > Cc: Pat Calhoun; seamoby
> > 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
> > 
>