One document matched: draft-polk-dhc-uri-00.txt
DHC Working Group James Polk
Internet Draft Cisco Systems
Expiration: March 6th, 2006 September 6th, 2005
File: draft-polk-dhc-uri-00.txt
A Dynamic Host Configuration Protocol Option for
Requesting and Receiving Uniform Resource Identifiers
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 March 6th, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines a new Dynamic Host Configuration Protocol
(DHC) Option to allow one or more URIs to be transmitted from a
server to a client within one or more messages, and for one or more
URIs, each with a unique purpose, to be specifically requested by a
client of a server. Included in this Option is a purpose field to
identify the type of URI being requested by the client, or the type
of URI in the DHCP reply from the server.
Polk Expires March 6th, 2006 [Page 1]
Internet-Draft DHC URI Option Sept 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions used in this document . . . . . . . . . . . . 4
1.2 Terms, Acronyms and Definitions . . . . . . . . . . . . . 4
2. DHC Relay Option Format . . . . . . . . . . . . . . . . . . . 5
2.1 Rules of Usage . . . . . . . . . . . . . . . . . . . . . 5
3. Purposes of Different URI Types . . . . . . . . . . . . . . . 6
3.1 Primary SIP/SIPS URI of Public Safety Answering Point . . 7
3.2 Secondary SIP/SIPS URI of Public Safety Answering Point . 7
3.3 Client's Location By-Reference URI . . . . . . . . . . . 7
3.4 SIP/SIPS URI of Emergency Services Gateway (ESGW) . . . . 8
3.5 SIP/SIPS URI of Emergency Services Routing Proxy (ESRP) . 8
3.6 URI of Organization Providing LCI . . . . . . . . . . . . 8
3.7 URI for Geocoding or Reverse Geocoding Function . . . . . 8
3.8 Primary URI for Geo Mapping Service . . . . . . . . . . . 9
3.9 Secondary URI for Geo Mapping Service . . . . . . . . . . 9
3.10 Primary URI for Civic Mapping Service . . . . . . . . . . 9
3.11 Secondary URI for Civic Mapping Service . . . . . . . . . 9
4. Open Items for Discussion . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1 Normative References . . . . . . . . . . . . . . . . . . 11
8.2 Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . 12
1. Introduction
There are times in which a Uniform Resource Identifier (URI) is an
essential part of configuration information necessary for usage by
an endpoint (client) for the particular purpose of contacting what
is at that URI. This document defines a new Dynamic Host
Configuration Protocol (DHC) Option [RFC 2131] to allow URIs of
specific types, or purposes, to be requested by a client of a
server, and transmitted unrequested from a server to a client.
Because URIs can be used for many purposes, and to ensure
extensibility, this client option has a sub-option "purpose" field
to identify the type of URI included in the message.
The motivation of creating the ability to have sub-options within
the same DHCP Option here is because there are currently 11 unique
URIs described within this document, and each should not take up
valuable option number assignments when there is a limited set of
DHCP Option values. Therefore this document specifies one DHCP
Option for all URIs, allowing up to 255 uniquely identified URIs to
be defined as sub-options. This document will IANA Register each
purpose URI for interoperability.
Polk Expires March 6th, 2006 [Page 2]
Internet-Draft DHC URI Option Sept 2005
This document does not limit the means of an client from gaining
knowledge of a URI to DHCP, but provides DHCP as a means for a
client to gain knowledge of a URI or series of URIs determined
through local configuration, that are considered essential to that
client for use by applications within that client. This
determination MAY be made at client boot-up, or when a particular
application launches. One example of this URI download would be one
specifically for the SIP or SIPS URI of the appropriate Public
Safety Answer Point (PSAP) for the client when the user of that
client calls for emergency help (911 or 112-type of help). This is
not a transaction that should take place when a voice application
wants to make such a critical call set-up. It is more appropriate
that this information be downloaded to the client when the voice (or
other) application boots up in case it is needed at a later time.
An Internet Access Provider (IAP) would be in a better position to
have knowledge of where the client is than an Internet Service
Provider (ISP); the latter becoming more divorced from the physical
location of the client, especially in the case of the ISP being an
Application Service Provider (ASP) on a regional, national or
international scale. This was part of the motivation for Option 123
(GeoConf) [RFC 3825].
Examples of IAPs are DSL providers with known endpoints of their
cabling infrastructure, Hybrid Fiber Coax (HFC) Cable providers with
knowledge of where their logical endpoints are, and small or large
enterprise infrastructures. The DSL or HFC Cable provides are not
limited in this context to a single client at the subscriber's
endpoint, but could have few to many clients being served by an
access device of those infrastructures, all with a common need for
the particular URI, or series of URIs.
A client may request more than one URI be sent to it within the same
DHCPDISCOVER or DHCPREQUEST message. Each URI will be inside its
own payload container with an Option number, a length field and a
purpose field. This means that if more than one URI is being
requested or downloaded, there can be more than one DHCP Option XXX
(this document's option number) in the same IP message. Each URI
will be inside the DHCP Option payload shown in section 2 of this
document. There is no meaning to the order of URIs in a message.
Section 1.2 reviews the terminology and acronyms used in this
document that are fairly new to DHCP. Section 2.1 discusses the
rules of usage of this Option. Section 3 lists the unique numbering
of the purpose fields to the purpose type that is explained in
section 3.1 - 3.11. Section 4 discusses open issues to be
addressed. Section 5 is the IANA Considerations section of this DHCP
Option as well as the purpose field sub-options.
Polk Expires March 6th, 2006 [Page 3]
Internet-Draft DHC URI Option Sept 2005
1.1 Conventions used in this document
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 [RFC 2119].
1.2 Terms, Acronyms and Definitions
The following terms and acronyms are used within this document:
Civic Mapping - the process a server receiving the civic format
location of a client, processing that location to determine the
appropriate PSAP for that location, and returning that PSAP URI
to the client
Emergency Services Gateway - The special IP to circuit-switched
gateway that front-ends an emergency services Selective Router
(which directs all TDM based 911/112 type calls to the
appropriate PSAP)
Emergency Services Routing Proxy - a special instance of a SIP Proxy
that understands emergency routing to a PSAP based on the
location of the caller
ESGW - Emergency Services Gateway
ESRP - Emergency Services Routing Proxy
Geo Mapping - the process a server receiving the geo format location
of a client, processing that location to determine the
appropriate PSAP for that location, and returning that PSAP URI
to the client
IAP - Internet Access Provider
Internet Access Provider - typically the organization that provides
Internet or IP access to the client, and could be the same as the
ISP in certain circumstances
Internet Service Provider - Provider of advanced services, such as
application layer message processing, filtering and routing, and
services such as voice/video/instant messaging over IP, and could
be the same as the IAP in certain circumstances
ISP - Internet Service Provider
PSAP - Public Safety Answering Point
Public Safety Answering Point - the emergency response call center
talking the local emergency calls from people in distress. This
facility can be logical, and can transfer (reroute) any request
sent to it to another facility deemed more appropriate to receive
Polk Expires March 6th, 2006 [Page 4]
Internet-Draft DHC URI Option Sept 2005
the request.
2. DHC Relay Option Format
The format for this Option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code XXX | Length | URI Purpose | URI +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URI (cont'd) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URI (cont'd to a maximum of 254 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code = The IANA Assigned Option number
Length = This is a variable length value of the number of bytes
in the Option, including this length field
URI Purpose = This is what the URI is used for by applications
within the client
URI = This is a variable length field containing the URI
being transmitted, to a maximum of 254 bytes in length
This URI may be a partial URI, with concatenation-
required if multiple Option XXXs are present in the
same message with the same purpose value; see the
rules section below.
2.1 Rules of Usage
The following are the rules of usage of this DHCP Option:
- Each URI requested for by a client, or transmitted by the server,
MUST have a purpose identifier indicating the intended usage for
this URI by applications within the client
- there MAY be more than one URI requested by the client in the same
message
- If more than one URI is requested for by the client, or
transmitted by the server, each MUST be in separate Option fields
(i.e. there is no provision for multiple URIs within the same
Option as there is no length field for an individual URI)
- The certain URI fields MAY be populated with a URL of a server
Polk Expires March 6th, 2006 [Page 5]
Internet-Draft DHC URI Option Sept 2005
- Purpose=6 "URI of Organization Providing Location Configuration
Information" SHOULD be included when Option 123 (GeoConf) or the
Option for [ID-CIVIC] is downloaded to the client.
- URIs that denote public identifiers, such as for a PSAP, are not
as much at risk as other URIs transmitted to the client. That
said, URIs with specific information of the client, such as its
location by-reference URI SHOULD NOT be transmitted by the server
without being requested by the client first, and SHOULD only be
requested by the client once it learns the specific IP address of
the server.
In keeping with established rules of option lengths [RFC2131], the
length of a single option containing one URI MUST NOT exceed 255
bytes, unless following the rules established in [RFC3396] for
"concatenation-required" values, which states clearly that if the
same option appears more than once in the same message, to consider
that a split option value, to be concatenated prior to processing at
the receiving end.
This document provides a unique, therefore modified, usage of this
rule in DHCP, in which the literal meaning of [RFC3396] does not
apply, as this Option has sub-options (called 'purposes' here).
However, this [RFC3396] rule is modified here to state that:
- if the same purpose field value appears in the same message more
than once, the receiving entity MUST concatenate the URI values
prior to processing as a single value. This procedure MUST only
to be done when the URI value is longer than 255 bytes (per the
rules of [RFC2131] and [RFC3396]), therefore MUST NOT be done
otherwise.
The rest of [RFC3396] applies as written, as long as the reader
adjusts their understanding of that RFC to mean the purpose field in
this document, and not the Option field.
- multiple instances of this Option XXX in the same message with
different purpose values MUST NOT be considered for [RFC3396]
concatenation.
3. Purposes of Different URI Types
This section lists the initial set of purpose fields which can be
used by a client for different requests, or a server for different
transmissions:
Purpose = 1 (Primary PSAP URI)
Purpose = 2 (Secondary PSAP URI)
Purpose = 3 (Location By-Reference of Client)
Purpose = 4 (ESGW URI of Client)
Purpose = 5 (ESRP URI of Client)
Polk Expires March 6th, 2006 [Page 6]
Internet-Draft DHC URI Option Sept 2005
Purpose = 6 (Location Providing Location for Client)
Purpose = 7 (URI of Geocoding/Reverse Geocoding)
Purpose = 8 (Primary URI of Geo Mapping Service)
Purpose = 9 (Secondary URI of Geo Mapping Service)
Purpose = 10 (Primary URI of Civic Mapping Service)
Purpose = 11 (Secondary URI of Civic Mapping Service)
Others can be added based on discussion of this document.
3.1 Primary SIP/SIPS URI of Public Safety Answering Point (PSAP)
This purpose=1 URI is the primary URI used by a SIP [RFC3261]
enabled element in the Request-URI field for the appropriate PSAP
for this client when the SIP user agent (UA) is attempting to call
for emergency help (such as the police or ambulance).
3.2 Secondary SIP/SIPS URI of Public Safety Answering Point (PSAP)
Related to Purpose=1. This purpose=2 URI is the secondary or backup
SIP or SIPS URI of same PSAP facility or of another PSAP facility to
be used when the primary URI fails to connect, due to a timeout or a
SIP final failure message. This SHOULD NOT be used if the initial
attempt to contact the PSAP fails for any reason, as many failures
are recoverable within SIP [RFC 3261]. In fact, many non-successful
responses are not uncommon in SIP before a transaction is
successfully responded to.
3.3 Client's Location By-Reference URI
This purpose=3 URI is the pointer to the client's by-reference
location on a server external to the client [ID-SIP-LOC]. Location
of a client can be signified in two ways:
by-value - meaning the client possesses its location information
locally, and
by-reference - meaning the client's location information is
stored on a remote element such as a server.
Storing location information by-reference external to the client may
be for many reasons, including because the client does not know how
to store its location, because the client chooses to store it
remotely for a URI reference to be given to others to save bandwidth
during transmission, or because a service provider may decide to
keep this information from the client by-value. If the client knows
where its location is by-reference, it merely needs to provide that
reference to another entity when it decides to reveal where it is.
This URI is the retrieval identifier for a protocol to fetch the
client's location from. Examples of usable protocols are: HTTP,
Polk Expires March 6th, 2006 [Page 7]
Internet-Draft DHC URI Option Sept 2005
SIP, etc.
3.4 SIP/SIPS URI of Emergency Services Gateway (ESGW)
This purpose=4 URI is for the Emergency Services Gateway that an IP
client would contact when setting up an emergency call with a PSAP
that is not IP enabled. Having this information locally in the
client will allow it to contact the ESGW directly and not have to
rely on an intermediary to determine which ESGW is the right one for
this client, and possibly fail the call set-up during that
determination.
3.5 SIP/SIPS URI of Emergency Services Routing Proxy (ESRP)
This purpose=5 URI is for the Emergency Services Routing Proxy that
is tasked with determining which PSAP the client needs to contact
when attempting to establish a call with a PSAP. In SIP for
example, not all SIP Proxies or intermediaries are expected to have
knowledge of how to determine which is the appropriate PSAP of a
client based on where the client is located. There may be difficult
in a non-updated SIP intermediary in this determination, even in
determining which SIP intermediary knows how to do this function.
This SIP/SIPS URI is the Request-URI of such a SIP intermediary that
knows how to determine which is the correct PSAP given the included
PIDF-LO [ID-SIP-LOC] in the session set-up message (the SIP INVITE)
to that intermediary.
3.6 URI of Organization Providing Location Configuration Information
This purpose=6 URI is the organization that provided location
configuration information (LCI) to the DHCP client. In building a
proper XML Location Message Body [ID-PIDF-LO], the location
generator [RFC 3693] will include a <provided-by> element indicating
which organization was responsible for delivering this location
information to the client. This URI is used to populate this
<provided-by> element without further interaction.
3.7 URI for Geocoding or Reverse Geocoding Function
This purpose=7 URI of a server that can perform a geocoding or
reverse geocoding function. DHCP has the ability to provide
Location Configuration Information to a client in the geo format
using Option 123 [RFC 3825] or the civic format [ID-CIVIC], or the
client can learn is location through manual configuration or an
internal GPS process. Various applications on a client MAY prefer
one format over another and not possess the ability to geocode or
reverse geocode the available location information. This URI
(purpose=7) provides the client with the server known to have this
Polk Expires March 6th, 2006 [Page 8]
Internet-Draft DHC URI Option Sept 2005
ability prior to the client requiring the new format.
3.8 Primary URI for Geo Mapping Service
This purpose=8 URI gives the client the ability to transmit its
location, perhaps downloaded from DHCP Option 123 [RFC3825], and
contact a "primary" server at this URI to perform a location-to-
PSAP-URI mapping function before the client attempts to contact a
PSAP.
This transmission of client location to the primary mapping server
that includes the request to map this location to the appropriate
PSAP for that location is done with another protocol, and not DHCP.
3.9 Secondary URI for Geo Mapping Service
This purpose=9 URI gives the client the ability to transmit its
location, perhaps downloaded from DHCP Option 123 [RFC3825], and
contact a "secondary" server at this URI to perform a location-to-
PSAP-URI mapping function before the client attempts to contact a
PSAP.
This transmission of client location to the secondary mapping server
that includes the request to map this location to the appropriate
PSAP for that location is done with another protocol, and not DHCP.
3.10 Primary URI for Civic Mapping Service
This purpose=10 URI gives the client the ability to transmit its
location, perhaps downloaded from the civic format DHCP Option [ID-
CIVIC], and contact a "primary" server at this URI to perform a
location-to-PSAP-URI mapping function before the client attempts to
contact a PSAP.
This transmission of client location to the primary mapping server
that includes the request to map this location to the appropriate
PSAP for that location is done with another protocol, and not DHCP.
3.11 Secondary URI for Civic Mapping Service
This purpose=11 URI gives the client the ability to transmit its
location, perhaps downloaded from the civic format DHCP Option [ID-
CIVIC], and contact a "secondary" server at this URI to perform a
location-to-PSAP-URI mapping function before the client attempts to
contact a PSAP.
This transmission of client location to the secondary mapping server
that includes the request to map this location to the appropriate
Polk Expires March 6th, 2006 [Page 9]
Internet-Draft DHC URI Option Sept 2005
PSAP for that location is done with another protocol, and not DHCP.
4. Open Items for Discussion
There are several open items that need to be addressed in following
versions of this ID (if it moves forward).
#1 - Does Purpose=5 (URI of the ESRP) need to be pulled into two
separate URIs, one for a Routing Proxy that knows geo format
mapping, and the other that knows civic format mapping? This
may be too granular at this point.
5. IANA Considerations
IANA has assigned a DHCP option code of [XXX] for the URI option
defined in this document.
This URI Option defines one field for which IANA maintains a
registry: the Purpose field (see Section 2). The initial values of
the Purpose registry are as follows:
Purpose Description Reference
------- ------------ ---------
1 Primary PSAP URI [This RFC]
2 Secondary PSAP URI [This RFC]
3 Location By-Reference of Client [This RFC]
4 ESGW URI of Client [This RFC]
5 ESRP URI of Client [This RFC]
6 Location Providing Location for Client [This RFC]
7 URI of Geocoding/Reverse Geocoding [This RFC]
8 Primary URI of Geo Mapping Service [This RFC]
9 Secondary URI of Geo Mapping Service [This RFC]
10 Primary URI of Civic Mapping Service [This RFC]
11 Secondary URI of Civic Mapping Service [This RFC]
IANA registration of new purpose field values MUST be done in a
standards track RFC.
6. Security Considerations
Where critical decisions might be based on the value of this URI
option, DHCP authentication in [RFC3118] SHOULD be used to protect
the integrity of the DHCP options.
Since there is no privacy protection for DHCP messages, an
eavesdropper who can monitor the link between the client and
destination DHCP server to capture any URIs in transit.
Polk Expires March 6th, 2006 [Page 10]
Internet-Draft DHC URI Option Sept 2005
When implementing a DHC server that will serve clients across an
uncontrolled network, one should consider the potential security
risks.
7. Acknowledgements
To Andy Newton and Ralph Droms for guidance and assistance in the
shaping of this effort. To Josh Littlefield for his help.
8. References
8.1 Normative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002.
[RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic
Host Configuration Protocol (DHCPv4)", RFC 3396, November
2002
[RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,
"Geopriv Requirements", RFC 3693, February 2004
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[ID-PIDF-LO] J. Peterson, "Presence Information Data Format - Location
Object", draft-ietf-Geopriv-pidf-lo-03, "work in progress",
Sept 2004
8.2 Informative References
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001.
[ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", draft-ietf-
sip-location-conveyance-01.txt, "work in progress", June
2005
Polk Expires March 6th, 2006 [Page 11]
Internet-Draft DHC URI Option Sept 2005
[ID-CIVIC] H. Schulzrinne, " Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
Information ", draft-ietf-geopriv-dhcp-civil-06, "work in
progress", May 2005
Author's Address
James M. Polk
3913 Treemont Circle
Colleyville, Texas 76034
USA
Phone: +1-817-271-3552
Fax: none
Email: jmpolk@cisco.com
Intellectual Property Statement
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.
Disclaimer of Validity
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 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
Polk Expires March 6th, 2006 [Page 12]
Internet-Draft DHC URI Option Sept 2005
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Polk Expires March 6th, 2006 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-22 13:50:14 |