idnits 2.17.1 draft-petithuguenin-dispatch-unique-overlay-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4427 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-20 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-06) exists of draft-jennings-vipr-overview-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH M. Petit-Huguenin 3 Internet-Draft Unaffiliated 4 Intended status: Standards Track March 12, 2012 5 Expires: September 13, 2012 7 Infrastructure Overlay 8 draft-petithuguenin-dispatch-unique-overlay-02 10 Abstract 12 This document provides requirements for infrastructure overlays, a 13 special kind of peer-to-peer overlay whose main purpose would be 14 defeated if more than one instance would exist on the Internet. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. This document may not be modified, 20 and derivative works of it may not be created, except to format it 21 for publication as an RFC or to translate it into languages other 22 than English. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 13, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. VIPR Infrastructure Overlay . . . . . . . . . . . . . . . . 3 55 1.2. Bitcoin-like Infrastructure Overlay . . . . . . . . . . . . 3 56 1.3. BOINC-like Infrastructure Overlay . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 7.1. Normative References . . . . . . . . . . . . . . . . . . . 4 64 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 65 Appendix A. Proposal . . . . . . . . . . . . . . . . . . . . . . . 5 66 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . . 6 67 B.1. Modifications between -02 and -01 . . . . . . . . . . . . . 6 68 B.2. Modifications between -01 and -00 . . . . . . . . . . . . . 6 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 [RELOAD] is a peer to peer protocol developed by the P2PSIP Working 74 Group. Each RELOAD instance has a unique name, which is used by the 75 process in section 10.2 of this specification to find the 76 configuration servers, enrollment servers and bootstrap servers 77 needed to join the overlay. The process assumes that the RELOAD 78 instance name is a FQDN, and uses the process in [RFC2782] (SRV RR) 79 to find the IP address of the HTTPS server that serves the 80 configuration document for this overlay. 82 This process is adequate when the management of the overlay does not 83 need to be distinguished from the owner of the FQDN used as the 84 instance name, which is the case most of the time. But there is a 85 special class of overlays that, by definition, requires to be unique 86 on the Internet and for which having the possibility of create 87 instances would defeat their very purpose. This specification calls 88 the kind of overlays that are not domain specific, but application 89 specific "infrastructure overlays". 91 1.1. VIPR Infrastructure Overlay 93 [VIPR] is a technology that is being standardized in the VIPR Working 94 Group and that aims to build bridges between SIP islands by 95 automatically provision SIP routes after the "ownership" of a PSTN 96 phone number has been verified by an actual PSTN phone call. This 97 technology uses an RELOAD overlay as a distributed database where 98 mappings between phone numbers and servers responsible for the 99 validation process are stored. The promise of VIPR to bridge these 100 SIP islands cannot be fulfilled if there is more than one distributed 101 database storing these mappings. 103 1.2. Bitcoin-like Infrastructure Overlay 105 The existing Bitcoin [1] protocol is using an IRC channel to find the 106 initial peer servers, but one can imagine a Bitcoin-like Internet 107 currency that built on top of RELOAD. If such Internet currency is 108 ever implemented on top of RELOAD, it would also require a unique 109 RELOAD instance. 111 1.3. BOINC-like Infrastructure Overlay 113 BOINC [2] is a software for volunteer computing and grid computing, 114 which is used for donating computer resources for projects as diverse 115 as SETI@Home, Malariacontrol.net and LHC@Home. This kind of research 116 benefiting humanity as a whole could probably be better served if 117 implemented on a unique overlay. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 3. Requirements 127 The following requirements can be identified as a starting point for 128 the discussion about infrastructure overlays: 130 REQ-1: The mechanism used to find the configuration servers of the 131 infrastructure overlay MUST require as little administrative 132 overhead as possible. 133 REQ-2: The mechanism MUST NOT require that one entity must shoulder 134 the burden for administratively supporting the overlay. 135 REQ-3: The mechanism MUST ensure that no one can capture the overlay 136 for its own gain. 138 4. Security Considerations 140 TBD 142 5. IANA Considerations 144 This document requires no IANA actions. 146 6. Acknowledgements 148 Jon Peterson and Gonzalo Camarillo suggested to write this document, 149 with Jon Peterson providing some of the ideas. 151 This document was written with the xml2rfc tool described in 152 [RFC2629]. 154 7. References 156 7.1. Normative References 158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 159 Requirement Levels", BCP 14, RFC 2119, March 1997. 161 [RELOAD] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 162 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 163 Base Protocol", draft-ietf-p2psip-base-20 (work in 164 progress), January 2012. 166 7.2. Informative References 168 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 169 June 1999. 171 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 172 specifying the location of services (DNS SRV)", RFC 2782, 173 February 2000. 175 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 176 Part Four: The Uniform Resource Identifiers (URI)", 177 RFC 3404, October 2002. 179 [RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 180 Part Five: URI.ARPA Assignment Procedures", BCP 65, 181 RFC 3405, October 2002. 183 [VIPR] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- 184 Huguenin, "Verification Involving PSTN Reachability: 185 Requirements and Architecture Overview", 186 draft-jennings-vipr-overview-02 (work in progress), 187 September 2011. 189 URIs 191 [1] 193 [2] 195 Appendix A. Proposal 197 One possible way to implement infrastructure overlay is to do 198 something similar to [RFC3404] and [RFC3405], by defining a .arpa 199 subdomain named "reload". The overlay name as defined in a standard 200 track document then becomes a subdomain of "reload.arpa.", so if for 201 instance the name of an infrastructure overlay is "Quetzalcoatl", the 202 standard track document defining this overlay is also a request to 203 create a "Quetzalcoatl.reload.arpa." domain. 205 Because there is no way to clearly differentiate between a standard 206 overlay and an infrastructure overlay simply by looking at the 207 instance-name, especially since ICANN accepts applications for new 208 top-level domains, this proposal would also redefine the reload URI 209 in section 13.15 of [RELOAD], by prepending a '&' symbol to the name 210 of the overlay to signal that the name following the symbol is the 211 name of an infrastructure overlay. A RELOAD implementation 212 supporting infrastructure overlay can then use the procedure defined 213 in [RELOAD] section 10.2 by using the "reload.arpa." subdomain 214 instead of the instance name directly. 216 Appendix B. Release notes 218 This section must be removed before publication as an RFC. 220 B.1. Modifications between -02 and -01 222 o The proposal cares about the RELOAD URI, not the instance-name in 223 the configuration file. 225 B.2. Modifications between -01 and -00 227 o Added a proposal. 229 Author's Address 231 Marc Petit-Huguenin 232 Unaffiliated 234 Email: petithug@acm.org