VeriSign Research

1
VeriSign Research
2003 VNDS Applied Research Activities
July 29, 2003
2
2003 Projects
3
2003 Projects (cont)
4
2003 Projects (cont)
5
2003 Projects (cont)
6
2003 Projects (cont)
7
(No Transcript)
8
(No Transcript)
9
Overview
10
Applied Research

• Core purpose take a long term, broad view to
  help VGRS navigate
• Enhance current products/services
• Obsolete our own products/services to better
  business advantage
• Guidance maintain a roadmap 50k foot
  perspective vision principles
• Activities
• Develop proof of concept of new technologies for
  illustration
• Monitor emerging, potentially competitive,
  technologies
• Standardize solutions that need external
  participation for success

11
But that is not all

• Expert review and participation in both concepts
  and products for BUs
• Multilingual Redirect
• Root server activities
• Emerging directory activities
• Etc..
• Support for BU prototype and pilot efforts in a
  demo lab
• Both of these ideas are not fixed allocations
  that one can plan on

12
Internet future Where we fit

DNS, with DNSSEC
13
Nexus of Concepts
Strengths of Registry
Attributes of a Successful Service
Applied Research Concepts
Vision of the Future

• Attributes of a Successful Service
• Universality - Openness of internet with
  extensiblity to every connected node
• Globality - seen everywhere on the internet
• Openness - anyone can build services that makes
  buy-in cheaper
• Strengths of Registry (and company)
• DNS Core
• Basis of Directory Services
• Authentication Services
• Telephony
• Vision of the Future Of the Internet

14
Proof of Concept development goals

• Proposed proof of concept projects selected
• to demonstrate the feasibility of getting a
  critical mass of different technologies based on
  a core framework (e.g., for directories IRIS,
  dns-based naming authority)
• to push the envelope on understanding individual
  application/service needs (e.g., access control,
  search, internationalization)
• Individually may not be the right product steps
• Intended to put us in the position to respond,
  technologically, when the right product steps are
  clearer

15
Categories of Activities

• Neutral 3rd party infrastructure storage and
  retrieval services
• E.g., VoIP directory, whois beyond domain names
• Next-generation and non-network identifiers
• E.g., IDN, Xwords
• Security credentials for network activities
• E.g., DNSSEC, secure credentials registry

16
(No Transcript)
17
(No Transcript)
18
Activities Overview
19
Neutral 3rd Party Services
20
Directory Strategy in 3 Movements

• Phase 1
• Market-targeted, application- and
  operationally-oriented metadirectories based on
  data we have (e.g., secure e-mail directory,
  universal whois)
• Leverage Atlas infrastructure
• Phase 2
• Enhance Phase 1 metadirectories with reputation
  earned there, attract new data sources
  metadirectories
• Phase 3
• Promote new Internet information services based
  on the premise of our Internet Data Utility
  (always on, ubiquitous etc)

21
Directory Tech

• Exploring directory tech for VRSN future needs
• distributed
• federated
• managed access (access control, authentication)
• purposed query types
• eventually -- scalable searching
• Because these are characteristics of any future
  globally-scaled Internet infrastructure registry
  service

22
The method start with uwho...

• Problem solved
• need to know vs. privacy of information in whois,
  via structured data, distributed control, and
  access control
• Business drivers
• Community and ICANN mandate
• Definition of Success
• Provides a framework to build services on the
  structured data that currently is mandated and
  exists

23
... and then expand the strategy

• Follow-ons that use the same federated namespace,
  but that are currently decoupled
• security credentials (secure e-mail directory and
  application server keys)
• web services directory (for the small scale web
  services, not b2b as UDDI)
• etc
• Problem solved
• providing lookup across services that are not
  expected to be centralizable
• Definition of success
• Monetizable services possible because this data
  is accessible more reliably than ever thought
  possible

24
Technology project evolution
Secure Credentials Registry Enterprise-oriented
use case
ENUM registry Infrastructure play
Web Services Directory Naming registration
service opportunity
Universal Whois Opportunity to pursue IRIS in a
standards forum
IRIS Protocol Distributed, federated, access
controlled Common Indexing Query
Distribution Rudiments of search
25
Next Generation Identifiers
26
Getting there
PKI Domain-names
Domain-names
RealNames as-is
27
Security Credentials for network activities
28
Security, security, security

• Two key areas of interest for VGRS
• Infrastructure for locating security credentials
  and related material
• Securing DNS itself

29
(No Transcript)
30
(No Transcript)
31
(No Transcript)
32
External Activities
33
Voice over IP (VoIP) Security

• Main standards groups
• IETF SIP, SIPPING, MMUSIC, RTP, SRTP
• 3GPP SA3 (Security)
• Main VRSN participants
• Thomas Hardjono (?)
• Mark Kosters (Registry)
• Other (VTS) ?
• End goal
• Propagation of certificates and PKI for VoIP
  devices and services
• CALEA-related services
• Product directions
• TBD
• Milestones
• Device certificates for end-user VoIP devices
  (e.g. phones)
• Server certificates for SIP-related servers (e.g.
  SIP proxies)
• CALEA-registration of public-key pairs for lawful
  intercept of encrypted IP-based calls

34
DNS

• Main standards groups
• IETF DNS, DNSEXT, DNSOPS
• ICANN
• Main VRSN participants
• Mark Kosters
• Michael Mealling
• Dave Blacka
• Matt Larson
• End goal
• Monitor and participate in developments affecting
  core DNS service offerings
• Product directions
• DNS, DNSSEC
• Milestones
• DNSSEC standardization

35
Liberty Alliance

• Main standards groups
• Board Brian Matthews
• Marketing Brian Matthews
• Policy Shane Tews
• Technology Michael Mealling and Siddharth Bajaj
• End goal
• Build a federated identity management service
  and/or sub-services
• Ensure a managed service play in the architecture
  defined
• Intelligence gathering on industry direction
• Business opportunity identification
• Propagation of current products (certificates and
  PKI)
• Product directions
• Further investigate Attribute Broker and Identity
  Translation services
• Handle translation services (e.g. phone to email)
  Presence Directory
• Milestones
• Track Liberty v2 specifications

36
Global Internet Identifier Systems

• Main standards groups
• IETF IDN, APPS area
• IRTF SIREN research group
• W3C
• MINC
• Main VRSN participants
• Michael Mealling
• Leslie Daigle
• End goal
• Determine more opportunities for registerable
  identifier systems
• Product Directions
• Multilingual identifiers
• Layer-above-DNS naming (keywords)
• URN registries
• Milestones
• TBD

37
Directory and Registry Infrastructure Services

• Main standards groups
• IETF CRISP
• RIRs ARIN, RIPE, APNIC
• NANOG
• Main VRSN participants
• Andrew Newton
• Leslie Daigle
• Mark Kosters
• End goal
• New directory and registry services for IP and
  non-IP applications
• Product directions
• DNS Wild Card
• Universal Whois
• New infrastructure registries
• Milestones
• TBD

38
ENUM

• Main standards groups
• IETF ENUM
• ENUM Forum
• Main VRSN participants
• Michael Mealling
• End goal
• Monitor for Registry opportunities
• Product directions
• ENUM operator
• ENUM registry
• Milestones
• TBD

39
Regional Internet Registries

• Main standards groups
• RIPE
• ARIN
• APNIC
• Main VRSN participants
• Mark Kosters
• Leslie Daigle
• Andrew Newton
• End goal
• Monitor for partnering relationships (Internet
  infrastructure)
• Product directions
• Anything pertaining to Internet registry
  infrastructure
• Universal Whois
• Milestones
• TBD

40
Root Server Operation

• Main standards groups
• ICANN RSSAC, SECSAC
• Main VRSN participants
• Mark Kosters
• End goal
• Monitor and participate in policy development for
  root server operation
• Product directions
• Root server operation
• Milestones
• TBD

41
Legal Intercept

• Main standards groups
• ETSI
• OASIS
• ATIS T1
• Cable Labs
• GLIIF
• Main VRSN participants
• Pete Toscano
• Mark Kosters
• Tony Rutkowski
• End goal
• New operational services for service providers
  and law enforcement agencies
• Product directions
• Legal intercept services
• Milestones
• TBD

42
IPv6

• Main standards groups
• IETF IPv6, v6OPS
• RIRs ARIN, RIPE, APNIC
• NANOG
• Root Server Testbed network
• Main VRSN participants
• Mark Kosters
• Pete Toscano
• End goal
• Monitor IPv6 development and potential impact on
  core Registry Services
• Operational testbed for new DNS features in the
  Internet root
• Product directions
• TBD
• Milestones
• TBD

43
(No Transcript)
44
(No Transcript)
45
(No Transcript)
46
Projects/Technology Activities
47
(No Transcript)
48
Neutral 3rd Party Services

• Projects

49
(No Transcript)
50
ENUM

• Current Tasks
• Co-authoring update to the ENUM standard
• Helping Kevin McCandless (VTS) with ENUMForum
• Developing (with Andy) a proposal for using CRISP
  related work for ENUM
• Working with Directory Services on observing
  national deployment tests and developing business
  cases

51
Expected Value

• The expected value is associated with winning
  contracts for running ENUM deployments
• There are two types of potential contracts
• Per area code (NPA) within the NANP
• Per country (Tier 1)
• Our involvement along with Kevins involvement
  with the ENUM Forum maintains our current profile
  of involvement without commitment.
• The time to be non-committal is over.

52
Immediate Forecast

• National test beds and deployments are proceeded.
• USG has opted in to using ENUM and will be making
  recommendations soon for how the US will deploy
  ENUM.
• The time to be applying for these national and
  international contracts is now.

53
Universal Whois

• Compliance with Appendix W.
• Finally allows access controls on whois data
• Customers want this for privacy reasons
• Stops us from giving data away
• Potential for cert-based access control schemes
• Law enforcement
• Network operators
• Revenue sharing with registrars
• in the aspect of being a meta-directory
• Side-benefits
• Better relationship with ccTLD community.
• Better relationship with RIR community.
• potential for digital certificates

54
IRIS (Internet Registry Information Service)

• VeriSigns technical submittal to the IETF CRISP
  Working Group.
• XML-based whois
• CRISP
• Cross Registry Internet Service Protocol
• Created by the IETF at the request of VeriSign
• VeriSign also authoring the requirements document
• Part of .net re-compete strategy
• UWho
• Mostly being done via IRIS and CRISP
• ICANN Appendix W. agreement compliance

55
IRIS/CRISP Technical Documents

• draft-ietf-crisp-requirements-05
• draft-ietf-crisp-iris-core-03
• draft-ietf-crisp-iris-beep-03
• draft-ietf-crisp-iris-dreg-03
• draft-ietf-crisp-iris-areg-03

56
Secure Credentials Registry

• Goal maximize secure e-mail usage, hammering
  out new market space for our certificates
• Strategy solve the what is your cert problem
  impeding uptake today
• Note Many e-mail clients are S/MIME and
  directory capable today the problem is managing
  the certs

57
Secure E-mail Directory -- Strategy

• Become the single recognized source for locating
  e-mail certs (a branded directory)
• Cant store all certs in a centralized way -- but
  we can act as the gateway to finding them
• 1 Year set up and start promoting cert
  metadirectory (across our certs competitors)
• 2 Years use this as pki for web services
  activities
• 3 Years build out value-added services for all
  personal-cert related functions, and charge for
  registration in the enhanced metadirectory

58
XML Enhancements XML Scability Performance

• XML solves many problems, but it can also be
  slow.
• The complexities of XML Namespaces and XML
  Schemas only make things worse.
• Look at methodologies and strategies for making
  XML perform and scale in server environments.
• Common system and design patterns
• Gather research from other organizations
• Look at what various VeriSign developers are
  doing and enable cross-seeding

59
ENUM Endpoint Directory

• Whois-like service for eventual ENUM services
• Purpose
• ENUM proponents are realizing they need to
  provide white pages information around ENUM
  registrations, as whois does for DNS
  registrations
• Dont want to fall into the same tar pit as
  existing whois
• need access controls from the outset
• need uniform, structured query mechanisms
• Proposal
• Use the IRIS-based approach to support this
  whois-like functionality

60
Identity Discovery for Web Services

• Web services (as with most of the web) uses URIs
  as its basic unit of addressing.
• WSDL files are published on a web site but the
  location of everyones WSDL files is different,
  plus one site may have multiple WSDL files (I.e.
  imagine how all the people on Earthlink would
  publish a WSDL file).
• This project attempts to provide a very
  lightweight registration service for WSDL
  locations. A corresponding URN namespace will
  also be used to persistently name those
  collections.
• Once those locations are registered, a Common
  Indexing Protocol (CIP) service can harvest and
  consolidate those WSDL files so that entire space
  can be searched.
• Tasks
• IRIS spec for the registry
• Registrar webpage, self-registration to start
• Potentially a UDDI/UBR interface in order to
  allow existing client applications to use the CIP
  index
• Web page and web services based interfaces as
  well
• Potential integration with EPP to allow
  Registrars to handle the registration process
  internally

61
Internet Services Directory (Service Bureau)

• Leverage CRISP/IRIS work to become the
  one-stop-shop for network administrative data
• address registry
• routing registry
• XWords registrant registry
• ENUM registry
• Lay the foundation for authenticated routing
• Requires gaining the trust of the RIR community

62
Advantage of the Service Bureau

• Much of the data is freely available and
  necessary for the running of the Internet.
• But it is difficult to find and tricky to ask
  for.
• Lack of query standards
• Lack of useful tools
• Lack of location schemes
• gt general confusion
• gt unhappy users
• Strategy
• Aggregate when possible
• Navigate when necessary

63
Common Indexing/Query Routing

• Purpose evaluate feasibility and usefulness of
  different techniques for finding data in
  distributed, federated systems
• Problem characteristics
• we want to support lookups searches across
  services we dont control (e.g., other CA
  servers)
• cant centralize
• right now, depend on names to give us clues about
  where to go
• need an effective way to offload search from our
  primary lookup engines

64
Retrieval in Distributed Systems

• Potential techniques
• Common Indexing Protocol
• Query distribution
• Peer-to-peer model of search-support (distributed
  caches, etc)
• 2003 Target
• Develop a proof of concept for at least one
  technique to evaluate it in the specific context
  of one of our directory tasks (e.g., universal
  whois, secure credentials registry, web services
  directory)

65
(No Transcript)
66
Next Generation Identifiers

• Projects

67
(No Transcript)
68
Personal Internet Names (PINs)

• Horizontal identity framework that can realize
  the goal of a
• Universal
• Permanent
• Secure
• Private
• identity for a person or organization
• The goal is to roll out compelling identity
  products that use a horizontal framework that
  enables an assembly line/plugin approach to
  subsequent products.
• The current objective is to select those initial
  and compelling offerings while educating the
  consumer that other things are possible as well
  as shopping standardized parts of the system to
  external entities (Liberty)

69
The Architecture
Insurance, Inc.
Centralized Attribute Directory
70
The Applications

• Data View

• Application View

71
Steps currently in progress

• Registry is coordinating a cross-BU look at
  Identity in general (see identity.verisignlabs.com
  ) and the PIN architecture specifically as an
  identifier play
• The approach is to investigate a handful of
  applications to determine which combination is
  most compelling
• The DDDS identifier concept is being proposed to
  Liberty as a framework for Liberty Version 2.0s
  basic identifier infrastructure and metadata
  location service. The decision process is on
  going and will probably be dealt with extensively
  at the December meeting.

72
Xwords

• A forklift upgrade of VRSN core competency to
  capture the next generation global naming market
• VeriSign is brilliantly positioned as the
  operational infrastructure company . As such we
  are the only company that can actually deploy a
  new naming infrastructure and still be dominant
  afterward.
• We can keep doing point solutions (e.g.,
  keywords, WebNum, etc), but if we want to get to
  critical mass and realize the network effect, we
  need an open, non-proprietary solution that
  addresses the general problem
• Current status Being considered by the registry
  for future enhancements to ML.ML, financials
  being analyzed by Registry BD (first model
  suggests 34 million in revenue in year 1 and 94
  million by year 3 including COGs), standards work
  continuing within the IRTF, investigations being
  done to determine LOE of integrating CNRP plugin
  with iNav plugin.
• Next Steps determine sanity of financial
  analysis meeting with Engineering to determine
  preliminary costs and deployment roadmap combine
  and present to the Registry PDC during 1Q03

73
Getting there
PKI Domain-names
Domain-names
RealNames as-is
74
Product Roadmap

• Xwords is a product line based on a unifying
  platform of multifaceted, extensible, and
  internationalized keywords for human oriented
  identification of network services.
• Each product in the product line reinforces the
  platform
• Web pages (E-commerce branding, Multilingual
  e-commerce, Non-commercial sites)
• Messaging (Email, IM, SMS, WebNum)

• The Xwords platform

• Xwords are extensible keywords
• Based on our work with CNRP
• In participation with the IETF and other
  standards bodies
• 100 multilingual, including linguistic matching

• An open, horizontal infrastructure element that
  can be used as the basis for products not
  normally associated with keywords
• Email
• Instant Messaging
• Web page branding and location
• Wireless

75
What is it?

• A directory layer above DNS
• Engineered to handle non-unique names
• Can handle all UTF-8 characters, No length
  limits, no character restrictions (I.e. no
  nameprep)
• No root
• The service returns URLs, not hosts, making it
  much easier for a smaller granularity of Internet
  resources to have an identity
• User friendly email addresses allow users to have
  Don Telage_at_VeriSign instead of
  dtelage_at_verisign.com
• Consumers dont have to guess a companys name.
  Companies dont have to educate their customers
  on what their website name is
• John Wieland Homes domain is jw.com, not
  johnwieland.com. This requires them to have to
  educate their customers on what domain-name to
  use instead of just using the name thats most
  obvious and natural
• IDNs solution is only annoying non-western
  cultures. An XWords solution solves 120 of their
  perceived problem.
• The key difference between Xwords and typical
  keyword products is that a query includes not
  only the keyword but additional parameters that
  qualify the query
• Projects

• Category - The topic area that the keyword
  pertains to (services/computer/etc)
• Target Application - The type of application that
  is going to use the URI (email, web, IM)

• Language - The language that the keyword is in
  (Simplified Chinese, English, etc)
• Location - The geographic scope in which the
  keyword is valid (us-ca-mtview)

76
Auto-ID

• Auto-ID system is RFID tags plus a network in
  which to resolve and use them. Each RFID contains
  an Electronic Product Code (EPC).
• EPCs are resolved via the Object Name Service
  (ONS) which is really just DNS.
• The EPC Namespace looks like this
• ltmanager-blockgtltobject classgtltserial numbergt
• Example (inside the RFID tag)
• 010000A8900016f000169dc0
• Example (beyond the tag)
• Epc126973671482176
• Which gets turned into
• 367.2697.1.onsroot.org
• We are attempting to convince the Uniform Code
  Council (this industries ICANN) to let us run
  the onsroot.org portion for them.

77
Auto-ID and Contextualization

• ONS resolution of an EPC locates authoritative
  information which is, be definition, the
  manufacturer. The problem is that after the
  product leaves the manufacturers dock door, he no
  longer receives any of the cost savings from
  supply chain efficiencies, the retailer does.
  Thus, manufacturers refuse to handle track and
  trace information since they receive no gain for
  it.
• As the product moves throughout the supply chain
  information about that product may reside in many
  different locations with many different access
  policies and trust models.
• The architecture lacks a contextualization
  service locating information about an EPC with
  some given context (local, extranet, community,
  regional, global).
• We will be investigating providing this service
  as well.

78
Auto-ID Current Status (7/26/03)

• We will be running an externally available,
  public pilot of an ONS root by August 15 with
  integration into an IBM Pilot by the September
  15th EPC Symposium.
• This pilot should be considered production
  quality.
• We expect some movement on the ONS contract by
  the end of Q3 (?)
• We may also attempt to build the C15N pilot by
  mid September as well, depending on the feedback
  we get on the design. Resource allocation is a
  huge question for us.

79
Billing ID Service

• A similar opportunity has been dropped on us
  weve been asked to help support a biller
  identification service to help the routing and
  identification of bill generating companies.
• I.e. when you get a bill (electronic or paper) it
  contains biller identification number that can
  cut down on the error rate of online bill pay
  services.
• There are questions about whether or not the
  partner who wants us to do this can deliver the
  big players it needs (I.e. Quicken). But the fact
  that these services are growing suggests the
  vertical but global identifier market is growing.

80
(No Transcript)
81
Security Credentials for network activities
82
(No Transcript)
83
DNSSEC

• Problem
• Core technology is not authenticated
• Allows for spoofed DNS traffic
• Can make CERTS worthless for SSL
• Email redirected to someone else
• Solution
• Roll out authenticated DNS ala DNSSEC
• Problem is initial cost
• Formation of opt-in
• Have alternatives in
• opt-sideways
• Silly state
• Waiting on BU to decide to either
• Run with Full-on DNSSEC
• Build a consortium with ISC to roll out opt-in as
  an experiment

84
DNSSEC what is the value?

• Based on prelim work, the initial market is small
• However the potential is huge
• Help win .NET recompete
• Accelerate demand for DNS Hosting
• Accelerate demand for CERTS
• CERTS easily found in DNS
• Potential to be the OCSP replacement for CERTS
• Certificate Revocation and directory lookup are
  the Achilles heel of CERTs
• Other unthought-of services
• First case of customer-facing technical
  integration of VRSN and NSI

85
DNSSEC what is being done

• Registry Support
• BD support
• Engineering/ops support
• Evangelism
• Champion opt-in within IETF and workshops
• Work with ISC on
• Opt-sideways
• Silly state
• Consortium building

86
CALEA

• What is it?
• Computer Assistance for Law Enforcement Act
  (1994)
• Service providers (SPs) mandated to provide
  intercept access to law enforcement agencies
  (LEAs)
• SPs are considered both traditional telcos and,
  more recently, ISPs, and related providers
  (Hotmail, etc.)
• CALEA covers communications, not just voice
• Problem?
• Considered costly and not a core competence of
  the SPs or LEAs
• Requires legal and technical skills

87
CALEA Solution

• Net Discovery
• Service intercepts as the SPs agent
• Provide CALEA compliance testing to SPs
• Execute intercepts as the LEAs agent
• Act as an intercept aggregator for LEAs
• We have or soon will have customers for all the
  above

88
CALEA What is Applied Research Doing?

• Building IP Intercept Lab
• Test emerging software/hardware solutions
• Aid LEAs and SPs on what systems are the best
• Interoperability testing
• Leverage knowledge on rolling out IP Intercept
  service
• Providing troubleshooting for voice intercept
  test lab, part of which is in Lakeside II

89
Enhancements to IP Intercept

• Unify disparate lawful intercept standards
• Global Lawful Intercept Industry Forum (GLIIF)
• Convert from ASN.1 to XML
• GLIIF and OASIS LI-XML TC

90
XML Enhancements IP Intercept

• Based on VeriSign CALEA work.
• Convert older ASN.1 lawful intercept documents
  into XML.
• Part of the work underway by the OASIS Legal XML
  working group.

91
Secure End Points

• Purpose promote the use of certificates for all
  applications, network hosts and user host
  network entities (mobility)
• Problem
• how to recognize/trust an endpoint that is not
  necessarily a fixed host
• where to find application certificates (if not
  exchanged in protocol)
• DNS indirection may mean that the certificate
  presented by the end server is different from the
  label the client looked up
• 2003 Target
• Develop naming convention
• Pursue NAPTR-lite transiting trust from
  secure DNS

92
Other

• Projects

93
IPv6

• Problem
• Growth of the internet has shown warts in IPv4
• Number of max addresses
• Breaking of end-to-end ideal
• Mobile IP
• Solution
• Move to IPv6 when demand warrants

94
IPv6 What is the Value?

• This is an infrastructure must have
• Need to know behavior constraints on root and
  gtld name servers
• Testing forum for DNSSECopt-in
• Testbed live in 6Bone (a group of IPv6
  networkers)
• Help measure roll out time on the Internet

95
IPv6 What is Being Done?

• Authored a IP micro-allocation policy for GTLD
  servers
• Testbed for DNSSEC and IPV6 roots com/net in
  6Bone
• Potential list of ideas
• Multilingual DNS
• Authenticated Routing via DNSSEC

96
DNS Server Beacon

• Analysis of best dns sites is problematic
• Attempt to use measurement tools to discover the
  core of the Internet
• Discover who the clients are that hit our dns
  servers
• measure time for data to get to/from a client
• measure the number of networks that one needs to
  cross to get to a client
• Geographically locate the site
• Use visualization tools to find trends

97
Example of Site Comparison(larger bars to the
left is better)
98
Geographic Location
99
GEOPRIV

• Geo-location, Presence, and Privacy
• GEOPRIV is a working group in the IETF
• New co-chair Andy
• Possible opportunities
• Location Objects will be wrapped with S/MIME
  digital certificates required.
• Possible registry opportunity in running location
  servers.
• Architecture is split between location
  generators, location servers, and location
  consumers.

100
(No Transcript)
101
2003 Applied Research Objectives

• The end...
• ... of the beginning.

102
(No Transcript)
103
(No Transcript)