draft-ietf-weirds-redirects-00.txt   draft-ietf-weirds-redirects-01.txt 
Internet Engineering Task Force C. Martinez, Ed. Internet Engineering Task Force C. Martinez, Ed.
Internet-Draft A. Servin, Ed. Internet-Draft A. Servin, Ed.
Intended status: Informational D. Gomez Intended status: Informational LACNIC
Expires: April 18, 2013 G. Rada Expires: August 5, 2013 L. Zhou, Ed.
CNNIC
D. Gomez
G. Rada
LACNIC LACNIC
October 15, 2012 Feb 2013
LACNIC's Redirection Service for Number Resource RESTful WHOIS Queries Redirection Service for Registration Data Access Protocol
draft-ietf-weirds-redirects-00 draft-ietf-weirds-redirects-01
Abstract Abstract
The traditional WHOIS protocol has several important shortcomings, The traditional WHOIS protocol has several important shortcomings,
and over the past few years several approaches to a better WHOIS have and over the past few years several approaches to a better
been discussed and proposed. Registration Data Access Protocol (RDAP) have been discussed and
proposed.
Among these shortcomings, different registries operate different Among these shortcomings, different registries operate different
WHOIS services. For users this implies that several WHOIS queries to WHOIS services. For users this implies that several WHOIS queries to
different registries may be necessary in order to obtain data for a different registries may be necessary in order to obtain data for a
given resource. given resource.
This document describes a proof-of-concept redirection service for This document describes a redirection service for RESTful WHOIS
RESTful WHOIS queries as implemented by LACNIC. This service allows queries. This service allows users to query a single WHOIS service
users to query a single WHOIS service and be redirected to the and be redirected to the authoritative registry.
authoritative registry.
The main goal of this document is to encourage discussion on the
topics of Joint WHOIS services and query redirection in a RESTful
WHOIS world.
The solution implemented by LACNIC proposed here applies to numbering The solution implemented proposed here applies to Regional Internet
resources (IPv4, IPv6 and autonomous system numbers). Registries(RIRs) and Domain Name Registries(DNRs).
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2013. This Internet-Draft will expire on August 5, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Proposed Approach . . . . . . . . . . . . . . . . . . . . . . 4 2. Proposed Approach . . . . . . . . . . . . . . . . . . . . . . 4
2.1. The REST approach to web services . . . . . . . . . . . . 4 2.1. The REST Approach to Web Services . . . . . . . . . . . . 4
2.2. Query redirection for RESTful WHOIS queries . . . . . . . 5 2.2. Query Redirection for RESTful WHOIS Queries . . . . . . . 4
2.3. A global Joint WHOIS trough HTTP redirection . . . . . . . 5 2.3. A Single RESTful WHOIS trough HTTP Redirection . . . . . . 5
2.4. Loops in redirection . . . . . . . . . . . . . . . . . . . 9 2.4. Loops in Redirection . . . . . . . . . . . . . . . . . . . 6
3. LACNIC RESTful WHOIS redirector implementation . . . . . . . . 12 3. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Accessing the redirector . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
3.1.1. Redirection URI . . . . . . . . . . . . . . . . . . . 12 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5.1. Normative References . . . . . . . . . . . . . . . . . . . 10
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Informative References . . . . . . . . . . . . . . . . . . 10
5.1. Normative References . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
A user interested in obtaining registration information for a given A user interested in obtaining registration information for a given
number resource normally uses the WHOIS service provided by the RIRs number or domain resource normally uses the WHOIS service provided by
(AfriNIC, APNIC, ARIN, LACNIC and RIPE-NCC). the RIRs and DNRs.
In order avoid having to query several databases until obtaining an In order to avoid having to query several databases until obtaining
answer some approaches have been discussed and implemented in the an answer, some approaches have been discussed and implemented in the
past, most notably the Joint WHOIS [lacnic-joint-whois] initiative. past, most notably the Joint WHOIS [lacnic-joint-whois] initiative.
However, among other shortcomings, Joint WHOIS is implemented using However, among other shortcomings, Joint WHOIS is implemented using
proxies and server-side referrals. proxies and server-side referrals.
The RESTful approach to WHOIS services The RESTful approach to WHOIS services (draft-ietf-weirds-using-http
(draft-newton-weirds-arin-whoisrws [I-D.newton-weirds-arin-whoisrws], [I-D.ietf-weirds-using-http]) makes it comparatively easy to
draft-newton-rir-query [I-D.newton-et-al-weirds-rir-query],
[draft-lacnic-restful-whois]) makes it comparatively easy to
implement client-side redirects based on normal HTTP 1.1 semantics implement client-side redirects based on normal HTTP 1.1 semantics
and behavior. and behavior.
The goal of this I-D is to document LACNIC's current implementation The goal of this I-D is to describe a RESTful WHOIS redirection
of a RESTful WHOIS redirection service and to encourage discussion on service and to encourage discussion on the topic of redirects in this
the topic of redirects in this problem domain. problem domain.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Proposed Approach 2. Proposed Approach
2.1. The REST approach to web services 2.1. The REST Approach to Web Services
While a full introduction to REST and RESTful <http://www.rest.org> While a full introduction to REST and RESTful <http://www.rest.org>
interfaces is out of the scope of this document it is important to interfaces is out of the scope of this document it is important to
note that these interfaces employ the verbs defined in HTTP (GET, note that these interfaces employ the verbs defined in HTTP (GET,
POST, HEAD, DELETE) and HTTP response codes to signal the semantics POST, HEAD, DELETE) and HTTP response codes to signal the semantics
and outcomes of an operation. and outcomes of an operation.
As WHOIS is a read-only service only the GET verb is implemented. As WHOIS is a read-only service only the GET verb is implemented.
HTTP status codes provide signaling for errors and other conditions, HTTP status codes provide signaling for errors and other conditions,
including the concept of "client-side redirection" as outlined below. including the concept of "client-side redirection" as outlined below.
2.2. Query redirection for RESTful WHOIS queries 2.2. Query Redirection for RESTful WHOIS Queries
Each RESTful WHOIS server should answer directly only those queries Each RESTful WHOIS server should answer directly only those queries
for which it is authoritative. In this case, being authoritative for which it is authoritative. In this case, being authoritative
equals "having direct access to a given registry database". equals "having direct access to a given registry database".
For all other queries, a RESTful WHOIS server could provide a 301 For all other queries, a RESTful WHOIS server could provide a 301
MOVED PERMANENTLY Redirect answer pointing to an URL hosted on a MOVED PERMANENTLY redirect answer pointing to an URL hosted on a
different RESTful WHOIS server. different RESTful WHOIS server.
Currently the format of the RESTful WHOIS URIs is different across
implementations ([I-D.newton-weirds-arin-whoisrws], RIPE RESTful
Interface [1], [draft-lacnic-restful-whois]), so the redirecting
server implemented by LACNIC currently maps the original query URI to
the URI format expected by the receiving server.
As all requests are to be performed employing HTTP GETs, a user agent As all requests are to be performed employing HTTP GETs, a user agent
can transparently follow the HTTP 30x redirection hints ([RFC2616]) can transparently follow the HTTP 30x redirection hints ([RFC2616])
until obtaining a non-error answer (HTTP 20x) ) or an unrecoverable until obtaining a non-error answer (HTTP 20x) or an unrecoverable
error condition (HTTP 40x or 50x). error condition (HTTP 40x or 50x).
If the work of WEIRDS progresses far enough so that an uniform URI 2.3. A Single RESTful WHOIS trough HTTP Redirection
format is agreed upon, the need for server-side URI mappings may
become unnecessary.
LACNIC's current implementation splits the authoritative RESTful
WHOIS service from the redirection service. The redirection service
provides a "switching point" for the whole resource tree. No Inter-
RIR coordination, database replication nor RIR-side proxies are
needed.
2.3. A global Joint WHOIS trough HTTP redirection
A single redirection-only RESTful WHOIS server could provide a single
root to which all RIR RESTful WHOIS servers could point queries for
which they are not authoritative.
In LACNIC's implementation the redirect server's database was When a registry does not have the authoritative answers to the user
initialized from IANA's registries for IPv4, IPv6 and AS numbers. agent's query, user agent's query will be redirected to a
redirection-only RESTful WHOIS server which could provide the
authoritative WHOIS server address.
Implementation was very simple even when adding the server-side URI The redirect server is responsible for tracking and returning the
mapping requirement outlined above. LACNIC's staff was able to authoritative sources for IP, AS, domain name, name server or entity
implement a proof of concept redirect-only server in about two days queries. All the query format are described in the
of effort including importing IANA's IPv4 registry into a database draft-ietf-weirds-rdap-query [I-D.ietf-weirds-rdap-query] Until now,
and implementing URI mapping for LACNIC, ARIN and RIPE's RESTful there are some alternative solutions for the bootstrapping problem of
WHOIS services. redirect server, such as using DNS SRV or NAPTR records. But this
problem is out of scope of this document and will be discussed
further in the following drafts in WEIRDS working group.
Figure 1 shows the general scheme of a single WHOIS redirector Figure 1 shows the general scheme of a single RESTWhois Redirection
serving three different RIRs standalone WHOIS while providing a Service serving three different RIRs standalone RESTWhois while
seamless query interface to clients. providing a seamless query interface to clients.
...................... ......................
| | | |
| WHOIS REDIRECTOR | | WHOIS REDIRECTOR |
| | | |
`....................' `....................'
_, | ._ _, | ._
,,' | `. ,,' | `.
,-' | `-. ,-' | `-.
,-' | `._ ,-' | `._
skipping to change at page 7, line 32 skipping to change at page 6, line 36
<---------- HTTP 200 --------------------- | <---------- HTTP 200 --------------------- |
(WHOIS response is returned) | (WHOIS response is returned) |
| |
| |
. .
Querying WHOIS data for 23.1.1.1 Querying WHOIS data for 23.1.1.1
Figure 2 Figure 2
Figure 3 shows the output of the well-known 'wget' tool where the 2.4. Loops in Redirection
redirection hints (HTTP 301's) for the same query can be seen.
Figure 3 also shows how the URL mapping function operates,
transforming the LACNIC REST URI into an ARIN REST URI.
wget --output-document=-
http://restwhois.labs.lacnic.net/restfulwhois/ip/23.1.1.1
http://restwhois.labs.lacnic.net/restfulwhois/ip/23.1.1.1
Resolving restwhois.labs.lacnic.net (restwhois.labs.lacnic.net)...
200.7.84.21
Connecting to restwhois.labs.lacnic.net
(restwhois.labs.lacnic.net)|200.7.84.21|:80... connected.
HTTP request sent, awaiting response... 307 Temporary Redirect
Location: http://www.labs.lacnic.net/restwhois/rwhois_redir/ip/23.1.1.1
[following]
http://www.labs.lacnic.net/restwhois/rwhois_redir/ip/23.1.1.1
Resolving www.labs.lacnic.net (www.labs.lacnic.net)...
2001:13c7:7001:4000::10, 200.7.84.10
Connecting to www.labs.lacnic.net
(www.labs.lacnic.net)|2001:13c7:7001:4000::10|:80... connected.
HTTP request sent, awaiting response... 301 MOVED PERMANENTLY
Location: http://www.labs.lacnic.net/restwhois/rwhois_redir/ip/23.1.1.1/
[following]
http://www.labs.lacnic.net/restwhois/rwhois_redir/ip/23.1.1.1/
Connecting to www.labs.lacnic.net
(www.labs.lacnic.net)|2001:13c7:7001:4000::10|:80... connected.
HTTP request sent, awaiting response... 301 MOVED PERMANENTLY
Location: http://whois.arin.net/rest/ip/23.1.1.1 [following]
Resolving whois.arin.net (whois.arin.net)... 2001:500:31::47,
2001:500:13::46, 2001:500:13::47, ...
Connecting to whois.arin.net (whois.arin.net)|2001:500:31::47|:80...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 1038 (1.0K) [application/xml]
Saving to: `STDOUT'
--- output suppressed for brevity ---
Detailed 'wget' output for a RESTful WHOIS query for 23.1.1.1
Figure 3
2.4. Loops in redirection
When redirection is used there is always the risk that bogus user- When redirection is used there is always the risk that bogus user-
agents and applications or malicious user can create loops that in agents and applications or malicious user can create loops that in
turn may become Denial of Service attacks. turn may become Denial of Service attacks.
To minimize the risk of loops created by bogus applications and user- To minimize the risk of loops created by bogus applications and user-
agents operators MAY use the mechanism shown in Section 3.1. agents operators MAY use the mechanism shown in Section 3.1.
However, this mechanism could be forged and bypassed by malicious However, this mechanism could be forged and bypassed by malicious
users possibly creating a Denial of Service attack against the users possibly creating a Denial of Service attack against the
operator. To avoid completely the risk of DoS operators should use operator. To avoid completely the risk of DoS operators should use
other methods such as rate-limit and authentication that are outside other methods such as rate-limit and authentication that are outside
the scope of this document. the scope of this document.
One of the challenges by using redirection is loop avoidance. Even One of the challenges by using redirection is loop avoidance. Even
though recommendation from REFERENCE** indicates that user-agents though recommendation from REFERENCE** indicates that user-agents
should have a mechanism to break loops, due to sometimes not should have a mechanism to break loops, due to sometimes not
carefully coded user-agents and other applications or due to carefully coded user-agents and other applications or due to
malicious users' activities loops that could end up in a Denial of malicious users' activities loops that could end up in a Denial of
Service for the RESTful WHOIS operator. Service for the RESTful WHOIS operator.
A simple scenario that creates a loop is shown in Figure 4. An user A simple scenario that creates a loop is shown in Figure 3. A user
request (1) an object from Operator 1; Operator 1 do not have the request (1) an object from Operator 1; Operator 1 do not have the
object but it has a pointer that Operator 2 has it, so it redirects object but it has a pointer that Operator 2 has it, so it redirects
(2) the user to Operator 2; user request Object X to Operator 2 (3); (2) the user to Operator 2; user request Object X to Operator 2 (3);
Operator 2 does not have the object either object but it has a Operator 2 does not have the object either object but it has a
pointer that Operator 1 has it, so it redirects (4) the user to pointer that Operator 1 has it, so it redirects (4) the user to
Operator 1; it creates a loop (5). Operator 1; it creates a loop (5).
+--------------+ +--------------+ +--------------+ +--------------+
| | | | | | | |
| Operator A | | Operator B | | Operator A | | Operator B |
skipping to change at page 10, line 25 skipping to change at page 7, line 36
|_______________ | | _________________| |_______________ | | _________________|
| | | | | | | |
+--------------+ +--------------+
| | 5) Loop | | 5) Loop
| User | | User |
| | | |
+--------------+ +--------------+
A simple loop A simple loop
Figure 4 Figure 3
The loop described could be avoided by simple forbidding to redirect The loop described could be avoided by simple forbidding redirecting
a response when the query has been originated by a redirect. However a response when the query has been originated by a redirect. However
this solution only allows one redirection. A less restrictive this solution only allows one redirection. A less restrictive
approach forbidding redirection to only when the destination is the approach forbidding redirection to only when the destination is the
same than the originator for the redirection does not work either as same than the originator for the redirection does not work either as
shown in Figure 5. shown in Figure 4.
+--------------+ +--------------+ +--------------+ +--------------+
| | | | | | | |
| Operator A | | Operator B | | Operator A | | Operator B |
| | | | | | | |
+---^-----+----+ +----^----+----+ +---^-----+----+ +----^----+----+
1) | | 2) 3) | | 4)Redirect 1) | | 2) 3) | | 4)Redirect
Request | | Redirect Request | | to Request | | Redirect Request | | to
Object X | | to Object X | | Operator C Object X | | to Object X | | Operator C
| | Operator B | | | | Operator B | |
skipping to change at page 11, line 33 skipping to change at page 8, line 33
to Operator A | | Request to Operator A | | Request
| | Object X | | Object X
+--------\/----+ +--------\/----+
| | | |
| Operator C | | Operator C |
| | | |
+--------------+ +--------------+
A more complex loop. A more complex loop.
Figure 5 Figure 4
In the scenario depicted in Figure 5 the user request object X from
Operator A which redirects him/her to Operator B which in turn
redirects the user to Operator C. Operator C then redirects the user
back to Operator A again creating a loop.
To avoid loops created by not well-programmed user-agents or
applications when redirecting operators MAY append or modify a
special URI indicating that a redirection and how many times it has
been done. The format of the URI is described in the next section.
In the scenario depicted in Figure 5 the user request object X from In the scenario depicted in Figure 4 the user request object X from
Operator A which redirects him/her to Operator B which in turn Operator A which redirects him/her to Operator B which in turn
redirects the user to Operator C. Operator C then redirects the user redirects the user to Operator C. Operator C then redirects the user
back to Operator A again creating a loop. back to Operator A again creating a loop.
To avoid loops created by not well-programmed user-agents or To avoid loops created by not well-programmed user-agents or
applications when redirecting operators MAY append or modify a applications when redirecting operators MAY append or modify a
special URI indicating that a redirection and how many times it has special URI indicating that a redirection and how many times it has
been done. The format of the URI is described in the next section. been done. The format of the URI is described as follows.
3. LACNIC RESTful WHOIS redirector implementation
LACNIC's staff was able to implement a proof-of-concept WHOIS
redirect without committing to a large development effort (around 12
man-hours were consumed).
The redirector was implemented in the Python programming language and
employing the Django web framework library for handling HTTP requests
and responses.
The choice of technology was dictated more by the developers'
familiarity with it. No claim regarding performance or suitability
for a production service is made.
3.1. Accessing the redirector
Currently there are two ways for accessing the redirector:
o By querying LACNIC's RESTful WHOIS for a non-LACNIC resource:
wget --output-document=-
http://restwhois.labs.lacnic.net/restfulwhois/ip/23.1.1.1
o Directly at:
http://www.labs.lacnic.net/restwhois/rwhois_redir
The redirector currently supports queries for IPv4 address blocks
only, employing the REST URIs defined in [!REF:draft-lacnic-
restfulwhois].
The current implementation will provide a redirection to an empty
answer in case the resources are not found in its registry.
LACNIC's current plans currently include extending the redirector so
queries for IPv6 blocks as well as autonomous system numbers are
supported.
3.1.1. Redirection URI
When a RESTful WHOIS operator redirects an user to retrieve an object When a RESTful WHOIS operator redirects a user to retrieve an object
from another operator, the operator making the redirection operator from another operator, the operator making the redirection operator
MAY append or modify a special URI. MAY append or modify a special URI.
When using an URI to indicate redirection, the URI MUST have the When using an URI to indicate redirection, the URI MUST have the
following structure: following structure:
/redirect/[step] /redirect/[step]
Where [step] is a consecutive counter that MUST be increased by every Where [step] is a consecutive counter that MUST be increased by every
operator when the URI is encountered in a query object. operator when the URI is encountered in a query object.
When an operator is redirecting a query for the first time it MAY When an operator is redirecting a query for the first time it MAY
append the redirection URI to the original URL. If the redirection append the redirection URI to the original URL. If the redirection
URI is used, it MUST use the format previously described and it MUST URI is used, it MUST use the format previously described and it MUST
set "step" equal to 1. For example, the URL set "step" equal to 1. For example, the URL
"http://whois.lacnic.net/restfulwhois/ip/200.7.84.0/24" would be "http://whois.lacnic.net/restfulwhois/ip/200.7.84.0/24" would be
replaced by replaced by
skipping to change at page 13, line 26 skipping to change at page 9, line 22
replaced by replaced by
"http://whois.example.com/restfulwhois/ip/200.7.84.0/24/redirect/1" "http://whois.example.com/restfulwhois/ip/200.7.84.0/24/redirect/1"
If an operator receives a request with the redirect URI it first If an operator receives a request with the redirect URI it first
SHOULD check if "step" is shorter that the defined threshold. If it SHOULD check if "step" is shorter that the defined threshold. If it
does the operator SHOULD strip it and process the query. If the does the operator SHOULD strip it and process the query. If the
query requires further redirection the operator MAY use the query requires further redirection the operator MAY use the
redirection URI and it MUST increase "step" in one. redirection URI and it MUST increase "step" in one.
Operators that support the redirect URI MUST never process redirects Operators that support the redirect URI MUST never create a new
that contain a step value greater that their locally set threshold. redirect that contain a step value greater that their locally set
threshold. However if the operator has an authoritative response to
the agent it MUST respond regardless to the threshold value.
3. Service Discovery
TBD
4. Security Considerations 4. Security Considerations
This document makes no explicit security considerations other than Firstly, redirect server settings cannot be modified by someone other
those stated above. than the user validated by the redirection server.
Secondly, insure the redirection URL data must not be able to modify
URL in data transmission process. Such as
http://www.labs.lacnic.net/restwhois/rwhois_redir/ip/23.1.1.1 cannot
be modified to
http://www.labs.somenic.net/restwhois/rwhois_redir/ip/23.1.1.1.
While security practices are outside the scope of this document, the
authors believe it is important to identify such problematic use
cases to any DNR or RIR that may implement the redirection WHOIS
service.
5. References 5. References
5.1. Normative References 5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[min_ref] authSurName, authInitials., "Minimal Reference", 2006.
5.2. Informative References 5.2. Informative References
[I-D.newton-et-al-weirds-rir-query] [I-D.ietf-weirds-rdap-query]
Newton, A., Ranjbar, K., and A. Servin, "A Uniform RESTful Newton, A. and S. Hollenbeck, "Registration Data Access
URL Query Pattern for RIRs", Protocol Query Format", draft-ietf-weirds-rdap-query-02
draft-newton-et-al-weirds-rir-query-00 (work in progress), (work in progress), December 2012.
September 2011.
[I-D.newton-weirds-arin-whoisrws] [I-D.ietf-weirds-using-http]
Newton, A., "ARIN's RESTful Web Service for Whois Data", Newton, A., Ellacott, B., and N. Kong, "Using the
draft-newton-weirds-arin-whoisrws-00 (work in progress), Registration Data Access Protocol (RDAP) with HTTP",
June 2011. draft-ietf-weirds-using-http-01 (work in progress),
December 2012.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[draft-lacnic-restful-whois]
LACNIC, "LACNIC's RESTful WHOIS Interface for Registry
Data", 2011, <http://www.labs.lacnic.net/site/sites/
default/files/draft-lacnic-weirds-restwhois-03.pdf>.
[lacnic-joint-whois] [lacnic-joint-whois]
LACNIC, "Joint WHOIS", 2005, <ftp:// LACNIC, "Joint WHOIS", 2005, <ftp://
anonymous@ftp.registro.br/pub/gter/gter20/ anonymous@ftp.registro.br/pub/gter/gter20/
02-jwhois-lacnic.pdf>. 02-jwhois-lacnic.pdf>.
URIs
[1] <https://labs.ripe.net/ripe-database/database-api/
api-documentation>
Authors' Addresses Authors' Addresses
Carlos M. Martinez (editor) Carlos M. Martinez (editor)
LACNIC LACNIC
Rambla Mexico 6125 Rambla Mexico 6125
Montevideo, 11400 Montevideo, 11400
Uruguay Uruguay
Phone: +598-2604-2222 Phone: +598-2604-2222
Email: carlos@lacnic.net Email: carlos@lacnic.net
skipping to change at page 14, line 39 skipping to change at page 11, line 4
Authors' Addresses Authors' Addresses
Carlos M. Martinez (editor) Carlos M. Martinez (editor)
LACNIC LACNIC
Rambla Mexico 6125 Rambla Mexico 6125
Montevideo, 11400 Montevideo, 11400
Uruguay Uruguay
Phone: +598-2604-2222 Phone: +598-2604-2222
Email: carlos@lacnic.net Email: carlos@lacnic.net
Arturo L. Servin (editor) Arturo L. Servin (editor)
LACNIC LACNIC
Rambla Mexico 6125 Rambla Mexico 6125
Montevideo, 11400 Montevideo, 11400
Uruguay Uruguay
Phone: +598-2604-2222 Phone: +598-2604-2222
Email: aservin@lacnic.net Email: aservin@lacnic.net
Linlin Zhou (editor)
CNNIC
No. 4, South 4th Steet, Zhongguancun
Beijing, 100190
China
Phone: +8610-5881-2677
Email: zhoulinlin@cnnic.cn
Dario Gomez Dario Gomez
LACNIC LACNIC
Rambla Mexico 6125 Rambla Mexico 6125
Montevideo, 11400 Montevideo, 11400
Uruguay Uruguay
Phone: +598-2604-2222 Phone: +598-2604-2222
Email: dario@lacnic.net Email: dario@lacnic.net
Gerardo Rada Gerardo Rada
 End of changes. 41 change blocks. 
214 lines changed or deleted 106 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/