draft-ietf-weirds-bootstrap-07.txt   draft-ietf-weirds-bootstrap-08.txt 
Network Working Group M. Blanchet Network Working Group M. Blanchet
Internet-Draft G. Leclanche Internet-Draft Viagenie
Intended status: Standards Track Viagenie Intended status: Standards Track October 13, 2014
Expires: April 2, 2015 September 29, 2014 Expires: April 16, 2015
Finding the Authoritative Registration Data (RDAP) Service Finding the Authoritative Registration Data (RDAP) Service
draft-ietf-weirds-bootstrap-07.txt draft-ietf-weirds-bootstrap-08.txt
Abstract Abstract
This document specifies a method to find which Registration Data This document specifies a method to find which Registration Data
Access Protocol (RDAP) server is authoritative to answer queries for Access Protocol (RDAP) server is authoritative to answer queries for
a requested scope, such as domain names, IP addresses or Autonomous a requested scope, such as domain names, IP addresses or Autonomous
System numbers. System numbers.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 2, 2015. This Internet-Draft will expire on April 16, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used In This Document . . . . . . . . . . . . . . 3 2. Conventions Used In This Document . . . . . . . . . . . . . . 3
3. Structure of RDAP Bootstrap Service Registries . . . . . . . 3 3. Structure of RDAP Bootstrap Service Registries . . . . . . . 3
4. Domain Name RDAP Bootstrap Service Registry . . . . . . . . . 4 4. Domain Name RDAP Bootstrap Service Registry . . . . . . . . . 5
5. Internet Numbers RDAP Bootstrap Service Registries . . . . . 6 5. Internet Numbers RDAP Bootstrap Service Registries . . . . . 6
5.1. IPv4 Address Space RDAP Bootstrap Service Registry . . . 6 5.1. IPv4 Address Space RDAP Bootstrap Service Registry . . . 6
5.2. IPv6 Address Space RDAP Bootstrap Service Registry . . . 7 5.2. IPv6 Address Space RDAP Bootstrap Service Registry . . . 7
5.3. Autonomous Systems RDAP Bootstrap Service Registry . . . 8 5.3. Autonomous Systems RDAP Bootstrap Service Registry . . . 8
6. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Non-existent Entries or RDAP URL Values . . . . . . . . . . . 10 7. Non-existent Entries or RDAP URL Values . . . . . . . . . . . 10
8. Deployment and Implementation Considerations . . . . . . . . 10 8. Deployment and Implementation Considerations . . . . . . . . 10
9. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Formal Definition . . . . . . . . . . . . . . . . . . . . . . 11 10. Formal Definition . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Imported JSON Terms . . . . . . . . . . . . . . . . . . 11 10.1. Imported JSON Terms . . . . . . . . . . . . . . . . . . 11
10.2. Registry Syntax . . . . . . . . . . . . . . . . . . . . 12 10.2. Registry Syntax . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12.1. IPv4 Address Space RDAP Bootstrap Service Registry . . . 13 12.1. IPv4 Address Space RDAP Bootstrap Service Registry . . . 13
12.2. IPv6 Address Space RDAP Bootstrap Service Registry . . . 13 12.2. IPv6 Address Space RDAP Bootstrap Service Registry . . . 13
12.3. Autonomous System Number Space RDAP Bootstrap Service 12.3. Autonomous System Number Space RDAP Bootstrap Service
Registry . . . . . . . . . . . . . . . . . . . . . . . . 13 Registry . . . . . . . . . . . . . . . . . . . . . . . . 14
12.4. Domain Name Space RDAP Bootstrap Service Registry . . . 13 12.4. Domain Name Space RDAP Bootstrap Service Registry . . . 14
12.5. Policies and Additional Considerations . . . . . . . . . 14 12.5. Additional Consideration . . . . . . . . . . . . . . . . 14
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 14
14.2. Non-Normative References . . . . . . . . . . . . . . . . 15 14.2. Non-Normative References . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Querying and retrieving registration data from registries are defined Querying and retrieving registration data from registries are defined
in the Registration Data Access Protocol (RDAP) [I-D.ietf-weirds-rdap in the Registration Data Access Protocol (RDAP) [I-D.ietf-weirds-rdap
-query][I-D.ietf-weirds-using-http][I-D.ietf-weirds-json-response]. -query][I-D.ietf-weirds-using-http][I-D.ietf-weirds-json-response].
These documents do not specify where to send the queries. This These documents do not specify where to send the queries. This
document specifies a method to find which server is authoritative to document specifies a method to find which server is authoritative to
answer queries for the requested scope. answer queries for the requested scope.
The proposed mechanism is based on the fact that allocation data for TLDs, AS numbers, and network blocks are delegated by IANA to
domain names and IP addresses are maintained by IANA, are publicly registrars that then issue further delegations and maintain
available and are in a structured format. The mechanism assumes some information about them. Thus, obviously the bootstrap information
data structure within these registries. This document requests IANA needed by RDAP clients is best generated from data and processes
to create these registries for the specific purpose of RDAP use, already maintained by IANA, whose registries already exist at
herein named RDAP Bootstrap Service registries. An RDAP client [ipv4reg], [ipv6reg], [asreg], and [domainreg].
fetches the RDAP Bootstrap Service registries, extracts the data and
then does a match with the query data to find the authoritative The required new functionality in support of RDAP could be
registration data server and appropriate query base URL. accomplished by augmenting these registries to contain new fields, or
creating second parallel registries containing the extra fields whose
entries mirror the existing ones. Either approach will satisfy the
needs of this document. This document requests IANA to make these
registries available for the specific purpose of RDAP use, herein
named RDAP Bootstrap Service Registries. An RDAP client fetches the
RDAP Bootstrap Service Registries, extracts the data and then does a
match with the query data to find the authoritative registration data
server and appropriate query base URL.
2. Conventions Used In This Document 2. Conventions Used In This Document
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Structure of RDAP Bootstrap Service Registries 3. Structure of RDAP Bootstrap Service Registries
The RDAP Bootstrap Service Registries are made available as JSON The RDAP Bootstrap Service Registries, as specified in Section 12,
[RFC7159] objects. The JSON registry output starts with metadata will be made available as JSON [RFC7159] objects, to be retrieved via
such as a version identifier, a timestamp of the publication date of HTTP from a location as specified by IANA. The JSON object for each
the registry and a description. There exists a "services" element, registry will start with a series of members that contain metadata
which is an array of arrays. Each second level array contains two about the registry such as a version identifier, a timestamp of the
elements, each of them being an array (third-level arrays). The publication date of the registry and a description. Following that
first third-level array, named 'Entry array', contains all entries is a "services" member which contains the registry items themselves,
that have the same set of base RDAP URLs. The second third-level as an array. Each item of the array contains a second-level array,
array, named 'Service URL array', contains the list of base RDAP URLs with two elements, each of them being a third-level array.
usable for the entries found in the 'Entry array'. There is no
assumption of sorting except that the two arrays found in each There is no assumption of sorting except that the two arrays found in
second-level array MUST appear in the correct order: 'Entry array' each second-level array MUST appear in the correct order: The entries
first followed by 'Service URL array'. An example structure of the array are followed by the service URL array. An example structure of
JSON output of a RDAP Bootstrap Service Registry is illustrated: the JSON output of a RDAP Bootstrap Service Registry is illustrated:
{ {
"version": "1.0", "version": "1.0",
"publication": "YYYY-MM-DDTHH:MM:SSZ", "publication": "YYYY-MM-DDTHH:MM:SSZ",
"description": "Some text", "description": "Some text",
"services": [ "services": [
[ [
["entry1", "entry2", "entry3"], ["entry1", "entry2", "entry3"],
[ [
"https://registry.example.com/myrdap/", "https://registry.example.com/myrdap/",
skipping to change at page 10, line 39 skipping to change at page 10, line 39
mistyped information by the user. The DNS query could be to fetch mistyped information by the user. The DNS query could be to fetch
the NS records for the TLD domain. If the DNS answer is negative, the NS records for the TLD domain. If the DNS answer is negative,
then there is no need to fetch the new version of the registry. then there is no need to fetch the new version of the registry.
However, if the DNS answer is positive, this may mean that the However, if the DNS answer is positive, this may mean that the
currently cached registry is no longer current. The client could currently cached registry is no longer current. The client could
then fetch the registry, parse and then do the normal matching as then fetch the registry, parse and then do the normal matching as
specified above. This method may not work for all types of RDAP specified above. This method may not work for all types of RDAP
objects. objects.
o If the client knows the existence of an RDAP aggregator or o If the client knows the existence of an RDAP aggregator or
redirector and trusts that service, then it could send the query redirector and its associated base URL, and trusts that service,
to the redirector, which would redirect the client if it knows the then it could send the query to the redirector, which would
authoritative server that client has not found. redirect the client if it knows the authoritative server that
client has not found.
Some authorities of registration data may work together on sharing Some authorities of registration data may work together on sharing
their information for a common service, including mutual redirection their information for a common service, including mutual redirection
[I-D.ietf-weirds-redirects]. [I-D.ietf-weirds-redirects].
When a new object is allocated, such as a new AS range, a new TLD or When a new object is allocated, such as a new AS range, a new TLD or
a new IP address range, there is no guarantee that this new object a new IP address range, there is no guarantee that this new object
will have an entry in the corresponding bootstrap RDAP registry, will have an entry in the corresponding bootstrap RDAP registry,
since the setup of the RDAP server for this new entry may become live since the setup of the RDAP server for this new entry may become live
and registered later. Therefore, the clients should expect that even and registered later. Therefore, the clients should expect that even
skipping to change at page 11, line 28 skipping to change at page 11, line 29
string that matches some entries in the registries string that matches some entries in the registries
o nameservers o nameservers
o help o help
10. Formal Definition 10. Formal Definition
This section is the formal definition of the registries. The This section is the formal definition of the registries. The
structure of JSON objects and arrays using a set of primitive structure of JSON objects and arrays using a set of primitive
elements is defined in [RFC4627]. Those elements are used to elements is defined in [RFC7159]. Those elements are used to
describe the JSON structure of the registries. describe the JSON structure of the registries.
10.1. Imported JSON Terms 10.1. Imported JSON Terms
o OBJECT: a JSON object, defined in Section 2.2 of [RFC4627] o OBJECT: a JSON object, defined in Section 2.2 of [RFC7159]
o MEMBER: a member of a JSON object, defined in Section 2.2 of o MEMBER: a member of a JSON object, defined in Section 2.2 of
[RFC4627] [RFC7159]
o MEMBER-NAME: the name of a MEMBER, defined as a "string" in o MEMBER-NAME: the name of a MEMBER, defined as a "string" in
Section 2.2 of [RFC4627] Section 2.2 of [RFC7159]
o MEMBER-VALUE: the value of a MEMBER, defined as a "value" in o MEMBER-VALUE: the value of a MEMBER, defined as a "value" in
Section 2.2 of [RFC4627] Section 2.2 of [RFC7159]
o ARRAY: an array, defined in Section 2.3 of [RFC4627] o ARRAY: an array, defined in Section 2.3 of [RFC7159]
o ARRAY-VALUE: an element of an ARRAY, defined in Section 2.3 of o ARRAY-VALUE: an element of an ARRAY, defined in Section 2.3 of
[RFC4627] [RFC7159]
o STRING: a "string" as defined in Section 2.5 of [RFC4627] o STRING: a "string" as defined in Section 2.5 of [RFC7159]
10.2. Registry Syntax 10.2. Registry Syntax
Using the above terms for the JSON structures, the syntax of a Using the above terms for the JSON structures, the syntax of a
registry is defined as follows: registry is defined as follows:
o rdap-bootstrap-registry: an OBJECT containing a MEMBER version and o rdap-bootstrap-registry: an OBJECT containing a MEMBER version and
a MEMBER publication and a MEMBER description and a MEMBER a MEMBER publication and a MEMBER description and a MEMBER
services-list services-list
skipping to change at page 13, line 7 skipping to change at page 13, line 7
By providing a bootstrap method to find RDAP servers, this document By providing a bootstrap method to find RDAP servers, this document
helps to ensure that the end-users will get the RDAP data from an helps to ensure that the end-users will get the RDAP data from an
authoritative source, instead of from rogue sources. The method has authoritative source, instead of from rogue sources. The method has
the same security properties as the RDAP protocols themselves. The the same security properties as the RDAP protocols themselves. The
transport used to access the registries could be more secure by using transport used to access the registries could be more secure by using
TLS [RFC5246] if IANA supports it. TLS [RFC5246] if IANA supports it.
12. IANA Considerations 12. IANA Considerations
IANA is requested to implement the following registries in JSON IANA is requested to make the RDAP Bootstrap Services Registries
format conformant to the syntax defined in Section 10. described below available as JSON objects, the syntax of which are
described by section 10. The process for adding or updating entries
into these registries does not correspond to the registration
policies described in [RFC5226]; as stated earlier, these registries
are generated from the data, processes, and policies maintained by
IANA in their allocation registries ([ipv4reg], [ipv6reg], [asreg],
and [domainreg]). IANA is expected to generate the RDAP Bootstrap
Services Registries data from these above mentioned registries,
according to their own registration policies. This document does not
extend or otherwise change those policies.
Each of the RDAP Bootstrap Services Registries needs to be made
available for general public on-demand download in the JSON format at
a location determined by IANA.
IANA is also advised that the download demand for the RDAP Bootstrap
Services Registries may be unusually high compared to other
registries that exist already. The technical infrastructure by which
registries are published may need to be reviewed.
Multiple entries pointing to the same set of URLs are grouped Multiple entries pointing to the same set of URLs are grouped
together in an array. Since multiple entries of non contiguous space together in an array. Since multiple entries of non contiguous space
may be grouped together, the registry may not be sortable by entries, may be grouped together, the registry may not be sortable by entries,
therefore it is not required or expected that the entries be sorted therefore it is not required or expected that the entries be sorted
in a registry. in a registry.
12.1. IPv4 Address Space RDAP Bootstrap Service Registry 12.1. IPv4 Address Space RDAP Bootstrap Service Registry
Entries in this registry contain at least the following: Entries in this registry contain at least the following:
skipping to change at page 14, line 5 skipping to change at page 14, line 23
12.4. Domain Name Space RDAP Bootstrap Service Registry 12.4. Domain Name Space RDAP Bootstrap Service Registry
Entries in this registry contain at least the following: Entries in this registry contain at least the following:
o a domain name attached to the root being registered o a domain name attached to the root being registered
o one or more URLs that provide the RDAP service regarding this o one or more URLs that provide the RDAP service regarding this
registration. registration.
12.5. Policies and Additional Considerations 12.5. Additional Consideration
It is envisioned that these new registries will have similar entries
than the corresponding IANA allocation registries, such as [ipv4reg],
[ipv6reg], [asreg], [domainreg], and possibly similar registration
policies. Given that the data required by RDAP clients is limited
compared to the content of the existing corresponding registries, and
given that this data has to be made available in a JSON format using
a specific key/value structure, this document is not defining an
extension of the existing IANA allocation registries. The
registration policies for the new registries of this document are
left to IANA.
IANA should make sure that the service of those registries is able to
cope with a larger demand and should take appropriate measures such
as caching, load balancing and redundancy.
The base URL of these registries is not defined in this document and
is left to IANA.
The HTTP Content-Type returned to clients accessing the JSON output The HTTP Content-Type returned to clients accessing the JSON output
of the registries MUST be "application/json" as defined in [RFC7159]. of the registries MUST be "application/json" as defined in [RFC7159].
13. Acknowledgements 13. Acknowledgements
The WEIRDS working group had multiple discussions on this topic, The WEIRDS working group had multiple discussions on this topic,
including a session during IETF 84, where various methods such as in- including a session during IETF 84, where various methods such as in-
DNS and others were debated. The idea of using IANA registries was DNS and others were debated. The idea of using IANA registries was
discovered by the editor during discussions with his colleagues as discovered by the editor during discussions with his colleagues as
well as by a comment from Andy Newton. All the people involved in well as by a comment from Andy Newton. All the people involved in
these discussions are herein acknowledged. Linlin Zhou, Jean- these discussions are herein acknowledged. Linlin Zhou, Jean-
Philippe Dionne, John Levine, Kim Davies, Ernie Dainow, Scott Philippe Dionne, John Levine, Kim Davies, Ernie Dainow, Scott
Hollenbeck, Arturo Servin, Andy Newton, Murray Kucherawy, Tom Hollenbeck, Arturo Servin, Andy Newton, Murray Kucherawy, Tom
Harrison, Naoki Kambe, Alexander Mayrhofer, Edward Lewis have Harrison, Naoki Kambe, Alexander Mayrhofer, Edward Lewis, Pete
provided input and suggestions to this document. The section on Resnick have provided input and suggestions to this document.
formal definition was inspired by section 6.2 of [RFC7071]. Guillaume Leclanche was a co-editor of this document for some
revisions; his support is therein acknowledged and greatly
appreciated. The section on formal definition was inspired by
section 6.2 of [RFC7071].
14. References 14. References
14.1. Normative References 14.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.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002. Internet: Timestamps", RFC 3339, July 2002.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, August 2010.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, March 2014.
14.2. Non-Normative References 14.2. Non-Normative References
[I-D.ietf-weirds-json-response] [I-D.ietf-weirds-json-response]
Newton, A. and S. Hollenbeck, "JSON Responses for the Newton, A. and S. Hollenbeck, "JSON Responses for the
Registration Data Access Protocol (RDAP)", draft-ietf- Registration Data Access Protocol (RDAP)", draft-ietf-
weirds-json-response-09 (work in progress), September weirds-json-response-10 (work in progress), October 2014.
2014.
[I-D.ietf-weirds-rdap-query] [I-D.ietf-weirds-rdap-query]
Newton, A. and S. Hollenbeck, "Registration Data Access Newton, A. and S. Hollenbeck, "Registration Data Access
Protocol Query Format", draft-ietf-weirds-rdap-query-14 Protocol Query Format", draft-ietf-weirds-rdap-query-15
(work in progress), September 2014. (work in progress), October 2014.
[I-D.ietf-weirds-redirects] [I-D.ietf-weirds-redirects]
Martinez, C., Zhou, L., and G. Rada, "Redirection Service Martinez, C., Zhou, L., and G. Rada, "Redirection Service
for Registration Data Access Protocol", draft-ietf-weirds- for Registration Data Access Protocol", draft-ietf-weirds-
redirects-04 (work in progress), July 2014. redirects-04 (work in progress), July 2014.
[I-D.ietf-weirds-using-http] [I-D.ietf-weirds-using-http]
Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the
Registration Data Access Protocol (RDAP)", draft-ietf- Registration Data Access Protocol (RDAP)", draft-ietf-
weirds-using-http-12 (work in progress), September 2014. weirds-using-http-13 (work in progress), October 2014.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for [RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for
Reputation Interchange", RFC 7071, November 2013. Reputation Interchange", RFC 7071, November 2013.
[RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext
Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June
2014. 2014.
skipping to change at page 16, line 22 skipping to change at page 16, line 25
[ipv4reg] Internet Assigned Numbers Authority(IANA), , "IPv4 Address [ipv4reg] Internet Assigned Numbers Authority(IANA), , "IPv4 Address
Space", <http://www.iana.org/assignments/ipv4-address- Space", <http://www.iana.org/assignments/ipv4-address-
space/ipv4-address-space.xml>. space/ipv4-address-space.xml>.
[ipv6reg] Internet Assigned Numbers Authority(IANA), , "IPv6 Global [ipv6reg] Internet Assigned Numbers Authority(IANA), , "IPv6 Global
Unicast Address Assignments", Unicast Address Assignments",
<http://www.iana.org/assignments/ipv6-unicast-address- <http://www.iana.org/assignments/ipv6-unicast-address-
assignments/ipv6-unicast-address-assignments.xml>. assignments/ipv6-unicast-address-assignments.xml>.
Authors' Addresses Author's Address
Marc Blanchet Marc Blanchet
Viagenie Viagenie
246 Aberdeen 246 Aberdeen
Quebec, QC G1R 2E1 Quebec, QC G1R 2E1
Canada Canada
Email: Marc.Blanchet@viagenie.ca Email: Marc.Blanchet@viagenie.ca
URI: http://viagenie.ca URI: http://viagenie.ca
Guillaume Leclanche
Viagenie
246 Aberdeen
Quebec, QC G1R 2E1
Canada
Email: Guillaume.Leclanche@viagenie.ca
URI: http://viagenie.ca
 End of changes. 26 change blocks. 
77 lines changed or deleted 89 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/