Subject: RE: [seamoby] [MOBILE-IP] BURP BOF

From: "Gary Kenward" <[email-masked]>
Date: Sun, 21 Jan 2001 16:26:56 -0500

Maybe someone should ask Raj Patil, seeing as he supported the
creation of SeaMoby. Perhaps he simply lumped SeaMoby in with 
MIP for simplicities sake.

gary

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, January 19, 2001 1:05 PM
> To: [email-masked]
> Subject: [seamoby] [MOBILE-IP] BURP BOF
> 
> 
> 
> 
> According to the description of this new BOF, mobile IP 
> already provides
> "seamless and continuous connectivity".  Hmm, what in the world
> is SeaMoby for?
> 
> Creating a standardized registration protocol for the  
> application layer
> makes a lot of sense.  Perhaps some of the UPnP/SLP work can be
> useful here.
> 
> 
> ---------------------- Forwarded by Phil Neumiller/MW/US/3Com 
> on 01/19/2001
> 11:48 AM ---------------------------
> 
> Please respond to [email-masked]
> 
> Sent by:  Basavaraj Patil <[email-masked]>
> 
> 
> A BOF on Basic User Registration Protocol (BURP)
> 
> 
> Charter:
> 
> The vision of pervasive computing also includes constantly being
> connected and the ability to access the Internet or the enterprise
> over the Internet. Mobile computing solutions based on protocols such
> as Mobile IP offer seamless and continuous connectivity for
> users. However a lot of roadwarriors and other types
> of users access the network from places like airports, hotels, malls
> and sports complexes. These environments may offer access to the
> network over wireless LANs or via Ethernet LAN ports or other
> mediums. In such scenarios,
> DHCP can provide configuration information  (e.g., giving a valid
> address etc.), but there is no standard way for service providers to
> obtain user information to perform AAA functions. For users
> who do not have Mobile IP clients on their devices but would like to
> access the network, they need to register and be authenticated by the
> local network service provider before being authorized to use the
> resources. The intent of this proposal is to develop an application
> layer registration protocol that allows a user to register in the
> local network by providing identity and authentication information
> to the local network which then uses a AAA infrastructure to validate
> the user, charge him and, authorize use of resources.
> 
> We would like to request a BOF on a "Basic User Registration
> Protocol (BURP)" for the March 2001 meeting of the IETF in 
> Minneapolis.
> The objective of the BOF will be to
> -- Detail the scope of the proposal and applicable scenarios
> 
> -- Chart a course and an action plan (including milestones
> and deliverables) for BURP.
> 
> -- Investigate  the impact on existing  AAA  protocols  and  make it
> flexible to support various authentication schemes.
> 
> The goal will be to define a standard UNI for  environments in which
> neither PPP nor Mobile IP is required but AAA interaction is
> essential.  The basic principle will include:
> 
>   -- The solution being a client-server application layer protocol
> 
>   -- Is applicable to both IPv4 and IPv6.
> 
>   -- User interacts only with a local Registration Agent (RA), which
>   may reside on any node in the Network Domain.
> 
>   -- It should work with any configuration  protocol, such as 
> DHCP, IPv6
>   stateless autoconfiguration, and manual configuration.
> 
>   -- Protects RA from replay attacks.
> 
>   -- Provide information on and control of network usage.
> 
>   -- Interacts with routers/policers to limit packets 
> forwarding based on a
>   user's Service Level  Specification  (may be optional or may
>   interwork with  standard policy protocols).
> 
>   -- Defines an RA-to-AAA interface
> 
> --------------------------------------------------------------
> ---------
> 
> To subscribe to the mailing list for discussion on this topic, please
> follow these instructions:
> 
> To subscribe, send mail to [email-masked], and
> use "subscribe" for the subject line.
> 
> To unsubscribe, send mail to [email-masked], and
> use "unsubscribe" for the subject line.
> 
> To contribute to the list, send mail to [email-masked].
> 
> For additional help, send mail to [email-masked]
> and use "help" for the subject line.
> 
> 
> 
>