idnits 2.17.1 draft-kessens-ride-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-ride-requirements-00', but the file name used is 'draft-kessens-ride-requirements-00' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (August 1997) is 9751 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) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force David Kessens 2 Draft ISI 3 Expires February 1998 August 1997 4 6 RIDE functional requirements 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 22 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Abstract 28 This document describes the (functional) requirements for the RIDE 29 format and protocols. 31 Introduction 33 The solution to the problem of exchanging information between 34 different Internet registry systems, and in particular the regional 35 IP registries, has a lot of requirements. Those requirements are 36 summarized in the first section. The second section describes the 37 actual functional requirements that should be supported in the 38 system. 40 Requirements 42 There are a couple of important requirements that need to be 43 considered when building an Internet registry exchange mechanism. 45 Draft RIDE Functional Requirements August 1997 47 - simple implemention 48 The new registry exchange format and protocols should be an easy, 49 simple and straight forward add-on to the current registry systems 50 in order to make it likely that the specification will be 51 implemented. 53 - no new registry system 54 The format and protocols are not intended to substitute one of the 55 current registry systems. They are intended to allow to let the 56 different registry systems to work together, as best as possible 57 without requiring major changes to the current systems. Therefore, 58 the design should be focussed solely to provide a framework for 59 cooperation with minimal bells and whistles. 61 - consistency and security issues 62 The formats and protocols will not make the registries data 63 consistent or secure by itself. All registries will have to work 64 that out individually for their own particular registry 65 implementation. However the design shall try not to increase 66 inconsistencies or pose additional security problems. We can also 67 consider to put forward some guidance for the individual registries 68 how they can deal with those issues. Due to the public nature of 69 the data that will be exchanged, security issues for the RIDE 70 protocols are mainly limited to proper authentication mechanisms 71 for the exchange of the full registry dataset and minimal exposure 72 to denial of service attacks. 73 - timing is important 74 While it is nice to design a system that will be able to cope with 75 every possible use in the future, we need a system right now. We 76 therefore prefer to design a simple but expandable exchange 77 mechanism rather than a perfect one which takes too long to define 78 and deploy. 80 - efficiency 81 Whatever mechanisms are choosen, it is expected that, specifically 82 for resolving references, the load on some servers in the system 83 could be fairly high. Loads could be of the same order of magnitude 84 as an ordinary non distributed registry server. In addition to 85 this, data volumes for an exchange of the full contents of a 86 registry system can be very high. 88 Functional requirements 90 Protocol requirements 92 - very simple but effective version negotiation mechanism 94 Draft RIDE Functional Requirements August 1997 96 There are two different types of functionality that are needed in 97 the system. Both are optional, the use of only one of the two 98 makes the system already very useful. 100 - retrieval of registry information for mirroring purposes 102 This feature will need optional identification of the querying 103 party for authorization purposes and possibly encryption 104 capabilities for ensuring the privacy of the information. 105 Information should be sent in a compressed format for efficiency 106 reasons. 108 The feature has two operating modes: 110 - retrieval of all the information stored in a registry 112 - retrieval of information that changed after the last retrieval 114 The incremental retrieval feature is optional. 116 - resolving of a reference 118 This feature will do a lookup of an object using an identifier 119 that is already known to the party doing the lookup. The 120 identifier format will be standarized by RIDE to make this 121 possible. The information is returned in RIDE format and the 122 querying software can return the data to the user in native 123 format by using it's mapping from RIDE to it's own formats. A 124 shortcut (not using the RIDE mapping) might be desired in case 125 two registries are talking together using the same registry 126 technology. 128 The data is already publicly available in the native format of 129 the registry and no identification or authorization for the 130 querying party is needed. 132 example: 134 An object in the ARIN registry references an object with contact 135 information using a NIC handle registered in the RIPE registry. 137 One does a query to the ARIN registry and the ARIN registry will 138 be able to resolve and display the referenced object from the 139 RIPE registry. 141 Format requirements 143 Draft RIDE Functional Requirements August 1997 145 The registry data itself will be represented in US ASCII. Regional 146 IP registries support only this, thus more is not needed. 147 Furthermore, it can be very difficult in an international 148 environment to use charactersets on a computersystem that is not 149 configured for it, and can be even more difficult when the 150 information is needed quickly to solve an operational problem. 152 Security considerations 154 Security considerations are dealt with in the regular sections 156 Acknowledgments 158 I would like to thank Kim Hubbard, Daniel Karrenberg, Dhaval Shah and 159 everybody that contributed to the work of the RIDE IETF working group 160 in general, for their various comments and suggestions. 162 Author's Address: 164 David Kessens, 165 ISI 166 4676 Admiralty Way, Suite 1001 167 Marina del Rey, CA 90292-6695 168 USA 169 davidk@ISI.EDU