view Side-By-Side changes

Geopriv                                                  J. Winterbottom
Internet-Draft                                                M. Thomson
Intended status: Standards Track                      Andrew Corporation
Expires: April 26, May 22, 2008                                 October 24,                                      H. Tschofenig
                                                  Nokia Siemens Networks
                                                       November 19, 2007


                        HELD Device identity Identity Extensions
       draft-winterbottom-geopriv-held-identity-extensions-03.txt
       draft-winterbottom-geopriv-held-identity-extensions-04.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 26, May 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).














Winterbottom & Thomson












Winterbottom, et al.      Expires April 26, May 22, 2008                  [Page 1]

Internet-Draft                 HELD-ID-EXT                  October                 November 2007


Abstract

   When a Location Information Server receives a request for location
   information (using the locationRequest message), described in the
   base HTTP Enabled Location Delivery (HELD) specification, it uses the
   source IP address of arriving message as a pointer to the location
   determination process.  This is appropriate in many environments.
   However, when an entity acting on behalf of the Target would like to
   request location information then the source IP address of the
   request will lead to wrong results.  In other cases the IP address is
   not the only identifier that serves as an input to the location
   determination procedure.

   This document extends the HELD protocol to allow the location request
   message to carry additional identifiers assisting the location
   determination process.  It defines a set of URIs for Device identities Target
   identifiers and a an XML containment schema.  These can be  As such, this extension
   is used in conjunction with HELD to provide Device identification beyond source IP Address. Target identification.
   Examples and usage in HELD message syntax are provided.
































Winterbottom, et al.      Expires May 22, 2008                  [Page 2]

Internet-Draft                 HELD-ID-EXT                 November 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4  5
   3.  Identity Extension Details . . . . . . . . . . . . . . . . . . . . . . . . . . .  5  6
     3.1.  URI Definitions  . . . . . . . . . . . . . . . . . . . . .  5  6
       3.1.1.  Ethernet MAC URI . . . . . . . . . . . . . . . . . . .  5  6
       3.1.2.  IP Address URIs  . . . . . . . . . . . . . . . . . . .  5  6
     3.2.  Device Identity  Schema . . . . . . . . . . . . . . . . . .  6 . . . . . . . .  7
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9 10
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10 11
     5.1.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 10 11
     5.2.  XML Schema Registration  . . . . . . . . . . . . . . . . . 10 11
     5.3.  Identifier 'type' Attribute values . . . . . . . . . . . . 11 12
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 13
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 14
     7.1.  Normative references . . . . . . . . . . . . . . . . . . . 13 14
     7.2.  Informative references . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Alternatives  . . . . . . . . . . . . . . . . . . . . 15 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 17





















Winterbottom & Thomson






























Winterbottom, et al.      Expires April 26, May 22, 2008                  [Page 2] 3]

Internet-Draft                 HELD-ID-EXT                  October                 November 2007


1.  Introduction

   Protocols

   Location Configuration Protocols, such as HELD [I-D.ietf-geopriv-http-location-delivery]
   [I-D.ietf-geopriv-http-location-delivery], need to identify a device Target
   in order to perform some task.  Basic determine its location.  The base HELD specification only
   provides device Target identity through the IP address of the requesting
   Target, while [I-D.ietf-geopriv-l7-lcp-ps] provides examples of where
   this may be insufficent. insufficient.  This memo defines a set of URIs an and a
   containment schema that allow allows the specification of device identity entity requesting location
   information to indicate a Target identifier beyond the source IP
   address and may be used with HELD and general
   presence documents as described in [RFC4479].









































Winterbottom & Thomson of the request.








































Winterbottom, et al.      Expires April 26, May 22, 2008                  [Page 3] 4]

Internet-Draft                 HELD-ID-EXT                  October                 November 2007


2.  Terminology

   The key conventions and terminology used in this document are defined
   as follows:

   This document reuses the terms Device and term Target, as defined in [RFC3693].

   This document uses the term Location Information Server, LIS as
   described in [I-D.ietf-geopriv-l7-lcp-ps].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].





































Winterbottom & Thomson









































Winterbottom, et al.      Expires April 26, May 22, 2008                  [Page 4] 5]

Internet-Draft                 HELD-ID-EXT                  October                 November 2007


3.  Identity Extension Details

   The

   This section defines the details of this memo consist of a simple the schema extension for HELD to
   support the inclusion of a device Target identity in the form of a URI or typed-token, and a
   typed-token.  A set of URI definitions that can be used for
   device identities. to specify
   these identities is also provided.

3.1.  URI Definitions

   The URIs defined in this section are designed to identify a device.
   The URIs identify the Device, Target;
   they do not identify measurements or sighting data associated with a Device,
   Target, such as the switch and port information to which the Device Target
   is attached (which can attached.  This information may, for example, be acquired using
   DHCP relay information [RFC3046] or LLDP [LLDP].  Device measurements
   and sighting data are described in
   [I-D.thomson-geopriv-held-measurements].  The identity provided may
   be transitory, such as an IP address that is leased from a DHCP
   server pool, but it MUST uniquely identify a device within a network
   at the time it is used. pool.

   The URIs in this section the following sub-sections are defined using ABNF
   (augmented Backus-
   Naur Backus-Naur form) described in [RFC2234].

3.1.1.  Ethernet MAC URI

   This is the Ethernet hardware address of the device.  The form of ABNF for
   this URI type is defined as:

   mac-uri = "mac:" 12*12HEXDIG

   This type of URI is, for example, used as example in [RFC4479] and this section provides
   the ABNF for this URI type. RFC 4479 [RFC4479].  An
   example of its use is provided in Figure 5.

   mac-uri = "mac:" 12*12HEXDIG

3.1.2.  IP Address URIs

   This section provides the ABNF for IP version 4 and IP version 6
   URIs.  One application of this URI scheme is described in
   [I-D.ietf-geopriv-l7-lcp-ps], where an outbound SIP proxy needs to
   make location requests to a LIS on-behalf-of on behalf of a Device Target because, for
   some reason, the necessary information was not provided by the
   Device.
   Target.

   ip-uri = "ip:" ipv4 / ipv6
   ipv4 = "IPv4+" IPv4-Address
   IPv4-Address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
   ipv6 = "IPv6+" hexpart [ ":" IPv4-Address ]
   hexpart =  hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
   hexseq  =  hex4 *( ":" hex4)
   hex4    =  1*4HEXDIG



Winterbottom & Thomson



Winterbottom, et al.      Expires April 26, May 22, 2008                  [Page 5] 6]

Internet-Draft                 HELD-ID-EXT                  October                 November 2007


   An example of a location request including a URI in this form to
   identify the Target device is shown in Figure 3.

   <locationRequest
          xmlns="urn:ietf:params:xml:ns:geopriv:held" responseTime="8">
     <locationType>geodetic</locationType>
     <heldDevice  xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
       <uri>ip:IPv4+192.0.2.5</uri>
     </heldDevice>
   </locationRequest>

            Figure 3: HELD Location Request Using an IP Address

   Note that the URI types are not case sensative sensitive and the iP:ipv4+
   192.0.2.5 is still a valid URI.

3.2.  Device Identity  Schema

   This section defines a schema that can be is used to provide device
   identities Target
   identifiers in a HELD location request.































Winterbottom & Thomson































Winterbottom, et al.      Expires April 26, May 22, 2008                  [Page 6] 7]

Internet-Draft                 HELD-ID-EXT                  October                 November 2007


   <?xml version="1.0"?>
   <xs:schema
   targetNamespace="urn:ietf:params:xml:ns:geopriv:held:id"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:heldDI="urn:ietf:params:xml:ns:geopriv:held:id"
   xmlns:xml="http://www.w3.org/XML/1998/namespace"
   elementFormDefault="qualified" attributeFormDefault="unqualified">

     <!-- typedURI definition -->

     <xs:complexType name="typedURI">
       <xs:simpleContent>
         <xs:extension base="xs:anyURI">
           <xs:attribute name="type" type="xs:token"
                         use="optional"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>

     <!-- typedToken definition -->

     <xs:complexType name="typedToken">
       <xs:simpleContent>
         <xs:extension base="xs:token">
           <xs:attribute name="type" type="xs:token"
                         use="required"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>


     <!-- Identity Parameters -->

     <xs:complexType name="idParameters">
       <xs:sequence>
         <xs:element name="uri" type="heldDI:typedURI"
                     minOccurs="0" maxOccurs="unbounded"/>
         <xs:element name="identifier" type="heldDI:typeToken"
                     minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
     </xs:complexType>

     <xs:element name="deviceIdentity" type="heldDI:idParameters"/>

   </xs:schema>

                             Figure 4: Device identity schema




Winterbottom & Thomson Schema




Winterbottom, et al.      Expires April 26, May 22, 2008                  [Page 7] 8]

Internet-Draft                 HELD-ID-EXT                  October                 November 2007


   The schema provided in Figure 4 allows a URI and/or token to be
   provided so that a Device Target can identify itself by more than just its
   IP address.  The URI can also include an optional "type" attribute so
   that URIs that might otherwise look the same can be distinguished
   based on their usage.

   For example <uri type="gruu">sip:callee@example.com</uri> or <uri
   type="aor">sip:callee@example.com</uri>

   When the <identifier> element is used the "type" attribute is
   mandatory as this it tells the LIS or receiving entity how to interpret
   the identifier.  An IANA registry is established for the central
   repository for recognized identifier types.  The set of initial types
   is provided in Section 5.3.

   A HELD location request sent by a device using the schema shown in
   Figure 4 to provide its identity as a mac MAC URI would look similar to
   Figure 5.

   <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
                    responseTime="8">
     <locationType>geodetic</locationType>
     <heldDevice xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
          <uri>mac:01ab34ef690c</uri>
     </heldDevice>
   </locationRequest>

                Figure 5: HELD Location Request URI example

   Similarly a device Target identifying itself using its DHCP client
   identifier (DHCP option 61 in [RFC2132]) in a location request to a
   LIS would send something similar to Figure 6.

   <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
                    responseTime="8">
     <locationType>geodetic</locationType>
     <heldDevice xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
          <identifier type="dhcpClientId">035552764</identifier>
     </heldDevice>
   </locationRequest>

            Figure 6: HELD Location Request Identifier example









Winterbottom & Thomson









Winterbottom, et al.      Expires April 26, May 22, 2008                  [Page 8] 9]

Internet-Draft                 HELD-ID-EXT                  October                 November 2007


4.  Security Considerations

   An Operator operator of a LIS that supports this schema extension needs to
   ensure that location provided to nodes requesting location in this
   manner are entitled to the location information being requested.  In
   some circumstances support of this schema extension will be
   inappropriate and alternative measures will need to be employed.












































Winterbottom & Thomson












































Winterbottom, et al.      Expires April 26, May 22, 2008                 [Page 9] 10]

Internet-Draft                 HELD-ID-EXT                  October                 November 2007


5.  IANA Considerations

   This document registers an XML namespace and schema with IANA in
   accordance with guidelines in [RFC3688].  It also creates a new
   registry for device identity types, and stipulates how new types are
   to be added.

5.1.  URN Sub-Namespace Registration for
      urn:ietf:params:xml:ns:geopriv:held:id

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in
   [RFC3688].

      URI: urn:ietf:params:xml:ns:geopriv:held:id

      Registrant Contact: IETF, GEOPRIV working group,
      (geopriv@ietf.org), James Winterbottom
      (james.winterbottom@andrew.com).

      XML:

       BEGIN
         <?xml version="1.0"?>
         <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
           "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
         <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
           <head>
             <title>HELD Device Identity Extensions</title>
           </head>
           <body>
             <h1>Namespace for HELD Device Identity Extensions</h1>
             <h2>urn:ietf:params:xml:ns:geopriv:held:id</h2>
   [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
       with the RFC number for this specification.]]
             <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
           </body>
         </html>
       END

5.2.  XML Schema Registration

   This section registers an XML schema as per the guidelines in
   [RFC3688].







Winterbottom & Thomson







Winterbottom, et al.      Expires April 26, May 22, 2008                 [Page 10] 11]

Internet-Draft                 HELD-ID-EXT                  October                 November 2007


   URI:  urn:ietf:params:xml:schema:geopriv:held:id

   Registrant Contact:  IETF, GEOPRIV working group, (geopriv@ietf.org),
      James Winterbottom (james.winterbottom@andrew.com).

   Schema:  The XML for this schema can be found as the entirety of
      Figure 4 of this document.

5.3.  Identifier 'type' Attribute values

   This document requests that the IANA create a new registry for
   identifier 'type' attribute values.  These are text strings that
   clarify how the value identifies the Device.  Referring to [RFC2434]
   this registry operates under the "Expert Review" rule.

   The following identifier types are registered as part of this memo:

   o  'dhcpClientId' The DHCP client identifier as defined by DHCP
      option 61 in [RFC2132]

   o  'msisdn' The Mobile Station International Subscriber Dial Number.
      This is an E.164 number made up of 6 to 15 digits

   o  'imsi' The International Mobile Subscriber identifier.  A unique
      identifier for GSM or UMTS mobile terminal made up of 6 to 15
      digits that identify the country code, the network code and
      device.

   o  'imei' The International Mobile Equipment identifier.  This is an
      electronic serial number for a mobile device and is consists of up
      to 15 digits

   o  'min' Mobile Identification Number.  A unique equipment identifier
      assigned to CDMA handsets.

   o  'mdn' Mobile Dial Number.  An E.164 number made up of 6 to 15
      digits.

   o  'hostname' The hostname or FQDN of the device.












Winterbottom & Thomson












Winterbottom, et al.      Expires April 26, May 22, 2008                 [Page 11] 12]

Internet-Draft                 HELD-ID-EXT                  October                 November 2007


6.  Acknowledgements

   The authors wish to thank the NENA VoIP location working group for
   their assistance in the definition of the schema used in this
   document.  Special thanks go to Barbara Stark, Guy Caron, Nadine
   Abbott, Jerome Grenier and Martin Dawson.  Thanks also to Bob Sherry
   for requesting that URI-types be supported which led to the typedURI
   form.











































Winterbottom & Thomson











































Winterbottom, et al.      Expires April 26, May 22, 2008                 [Page 12] 13]

Internet-Draft                 HELD-ID-EXT                  October                 November 2007


7.  References

7.1.  Normative references

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [I-D.ietf-geopriv-http-location-delivery]
              Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
              "HTTP Enabled Location Delivery (HELD)",
              draft-ietf-geopriv-http-location-delivery-02
              draft-ietf-geopriv-http-location-delivery-03 (work in
              progress), September November 2007.

   [I-D.ietf-geopriv-l7-lcp-ps]
              Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
              Location Configuration Protocol; Problem Statement and
              Requirements", draft-ietf-geopriv-l7-lcp-ps-05 (work in
              progress), September 2007.

   [I-D.thomson-geopriv-held-measurements]
              Thomson, M. and J. Winterbottom, "Using Device-provided
              Location Measurements in HELD",
              draft-thomson-geopriv-held-measurements-00 (work in
              progress), October 2007.

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

7.2.  Informative references

   [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
              J. Polk, "Geopriv Requirements", RFC 3693, February 2004.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [I-D.thomson-geopriv-held-measurements]
              Thomson, M. and J. Winterbottom, "Using Device-provided
              Location Measurements in HELD",
              draft-thomson-geopriv-held-measurements-00 (work in
              progress), October 2007.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [LLDP]     IEEE, "802.1AB, IEEE Standard for Local and Metropolitan
              area networks, Station and Media Access Control
              Connectivity Discovery", June 2005.

   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",



Winterbottom & Thomson



Winterbottom, et al.      Expires April 26, May 22, 2008                 [Page 13] 14]

Internet-Draft                 HELD-ID-EXT                  October                 November 2007


              RFC 3046, January 2001.

   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
              RFC 3966, December 2004.

   [RFC4479]  Rosenberg, J., "A Data Model for Presence", RFC 4479,
              July 2006.












































Winterbottom & Thomson   Expires April 26, 2008                [Page 14]

Internet-Draft                 HELD-ID-EXT                  October 2007


Appendix A.  Alternatives

   An alternative to providing the mobile identifiers as an <identifier>
   'type' they could be defined as URI types as shown below.  This would
   fit seeming well as other telephony device identifiers are already
   specified using telephone URIs [RFC3966].

   mobile-uri    = "mob:" mobile-identifier
   mobile-identifier = imsi / msisdn / imei / min / mdn
   imsi = "imsi:" 6*15DIGIT
   msisdn = "msisdn:" 6*15DIGIT
   imei = "imei:" 1*15DIGIT
   min = "min:" 1*15DIGIT
   mdn = "mdn:" 6*15DIGIT

   The URIs defined above allow an easy way for the Device to specify
   this binding to a LIS by using a HELD location request.  When the LIS
   receives the location request in Figure 9 it is able to bind the
   source IP address of the location request with the provided MSISDN.

   <locationRequest
         xmlns="urn:ietf:params:xml:ns:geopriv:held" responseTime="8">
     <locationType>geodetic</locationType>
     <heldDevice xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
         <uri>mob:msisdn:61448266004</uri>
     </heldDevice>
   </locationRequest>

               Figure 9: HELD Location Request Using MSISDN






















Winterbottom & Thomson












































Winterbottom, et al.      Expires April 26, May 22, 2008                 [Page 15]

Internet-Draft                 HELD-ID-EXT                  October                 November 2007


Authors' Addresses

   James Winterbottom
   Andrew Corporation
   PO Box U40
   University of Wollongong, NSW  2500
   AU

   Email: james.winterbottom@andrew.com


   Martin Thomson
   Andrew Corporation
   PO Box U40
   University of Wollongong, NSW  2500
   AU

   Email: martin.thomson@andrew.com

































Winterbottom & Thomson


   Hannes Tschofenig
   Nokia Siemens Networks
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Phone: +49 89 636 40390
   Email: Hannes.Tschofenig@nsn.com
   URI:   http://www.tschofenig.com






















Winterbottom, et al.      Expires April 26, May 22, 2008                 [Page 16]

Internet-Draft                 HELD-ID-EXT                  October                 November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Winterbottom & Thomson





Winterbottom, et al.      Expires April 26, May 22, 2008                 [Page 17]

----