Internet Engineering Task Force David Kessens Draft ISI Expires March 1998 Dhaval Shah Cisco Systems, Inc. Rick Wesson Organic Online, Inc. September 1997 RIDE Classes Status of this Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document describes the attributes and classes that will be used in the internet Registry Information Database Exchange formats (RIDE). For now it is mostly limited to 'domain' and 'contact' classes since they were widely considered as most urgent. Encoding that will be used for the objects and ways to find and access objects are beyond the scope of this document. This will be addressed in the future in separate drafts. Introduction This document follows a top-down approach. We will first describe the classes and then it's properties. Kessens [Page 1] Draft RIDE Classes September 1997 The properties are not absolutely defined. We expect certain attributes to have certain values, but we also expect that actual implementations are liberal in what they accept. Eg. being too restrictive when receiving attributes that have values violating the specification could degrade the usability of the scheme a lot while it doesn't really help with making a more reliable system. On the other hand, everybody that is going to create their own Internet registry is well advised to follow the guidelines of this document to maximize interoperatibility with other registries. We already talk in the document about formats while we explicitly told earlier not to deal with the actual dataformats yet. Assume those formats as examples of exactly which data is supposed to be carried in certain attributes, for clearness sake and as an advise how the contents could be shown to the *human* user. They don't however, tell anything yet, about how they will eventually be represented in the exchange format as will be defined in a separate document. Definition of the Contact class The contact class is a class that has two different functions. It defines contact information. Furthermore, it can work, when referenced by another object, as a macro definition for authentication information that can be used to authenticate a message or authorize an update to an object when the originator is properly authenticated. In addition to this functionality it may define information on how and who to notify of changes in the object that referenced the contact object. The contact class can be referenced by a NIC handle that will be guaranteed to be unique world wide [document needs to written] handle type title name organization address city state postalcode countrycode authscheme notifyonsuccess notifyonauthfailure Kessens [Page 2] Draft RIDE Classes September 1997 notifyoptions mail phone fax description url contactreference countries created updated aup registry handle: [mandatory] [single] Defines the world-wide unique identifier for this contact. Contact handles will be created by no more that the first three(3) words of the name attribute. type: [mandatory] [single] Defines whether the contact refers to an individual, an organization/role or whether it is used for authentication/notification purposes only. values: title: [optional] [single] Can be used to determine the function/title of an individual. name: [mandatory] [single] Full name of the contact person. organization: [mandatory] [single] The name of the Organization this contact belongs to. address: [optional] [multiple] The street or postal address for this(these) contact(s). city: [optional] [multiple] Kessens [Page 3] Draft RIDE Classes September 1997 If the Address attribute is a single line then this attribute should contain the city the contact resides in. state: [optional] [multiple] If this contact lives in a country that has states or provinces this should be used. postalcode: [optional] [multiple] countrycode: [optional] [multiple] The ISO-3166 Country Code this contact resides in. authscheme: [optional] [single] The Scheme used to authenticate requests that responsibilities have been delegated to this object. Contacts that wish to be delegated responsibility for another object (host or domain) must have valid AuthScheme and AuthInfo attributes. Multiple schemes can be used and logical combinations can be formed by using '&', '|' and '!' operators: < AuthScheme-1 | ( AuthScheme-2 & AuthScheme-3 ) > A scheme can be used for authentication purposes or authorization of update requests. Curently, the following schemes are known: CRYPT-PW Password is encrypted with the DES algorithm which is available on most UNIX systems as a library routine 'crypt'. MAIL-FROM Weak authorization schema. E-mail header 'From:' line is matched against the regular expression and updates are accepted when a match is found. PGP Server can authenticate messages by using the specified PGP public key. notifyonsuccess: [optional] [single] Kessens [Page 4] Draft RIDE Classes September 1997 This contains a list of Contacts and/or E-mail addresses of those who will want to receive a notification E-mail message when an object that references the Contact is successfully updated. notifyonauthfailure: [optional] [single] This will have the same syntax as NotifyOnSuccess but will only be used in case of an authorization/authentication failure when trying to update an object that references the Contact. notifyoptions: [optional] [single] A modifier for notification on use or modification. mail: [mandatory] [multiple] a valid e-mail address for this contact. If this contact does not have a valid notify attribute, this attribute will be used for correspondance. phone: [optional] [multiple] This is the internationsl telephone number to contact this contact. Please specify all dialing codes pertiant to your country. (required for CREATE, updateable) fax: [optional] [multiple] This attribute represents the facimlie number of this contact. description: [optional] [single] This attribute contains the description of the contact object. url: [optional] [multiple] List of url(s) that contain(s) possible interesting information about this object. contactreference: [mandatory] [multiple] This attribute references single or multiple contact objects by use of it's NIC handles. Each contact object has associated types and possibly some options: Technical Administrative Zone Kessens [Page 5] Draft RIDE Classes September 1997 Billing Generic Maintainer ( NEW, DEL, UPD, HIERNEW, HIERDEL, HIERUPD, ALL, HIERALL ) countries: [optional] [multiple] List of ISO-3166 country codes. The list tells something about the physical location of the entity described in the object. created: [mandatory] [single] A list of UTC dates when this object was created. updated: [mandatory] [single] A list of UTC dates when this object was updated. aup: [optional] [single] Acceptable Use Policy for this object. registry: [mandatory] [single] The Registry Identifier that manages this object. Definition of Domain class The Domain class describes DNS domain names together with technical and administrative data necessary for a proper operation of the DNS system. handle name organization contact ns status expireson description url contactreference countries created updated aup registry Kessens [Page 6] Draft RIDE Classes September 1997 handle: [mandatory] [single] Defines the unique identifier for this contact. Contact handles will be created by no more that the first three(3) words of the name attribute. name: [mandatory] [single] The Fully Qualified Domain Name. organization: [optional] [single] The organization, person or entity this domain represents. contact: [mandatory] [single] A reference (handle) to a Contact object that is responsible for this domain object. values: TECH | ADMIN | BILLING The format is TYPE/HANDLE. There can only be a maximum of one contact per type. ns: [mandatory] [multiple] this multivalued attribute contains a handle to a Host object that is deligated as authoritative for this zone (domain) requirements: A Minimum of 2, maximum of 12, status: [mandatory] [single] The status of the Domain. Values: RESERVED | WAIT | PRODUCTION | EXPIRED gooduntil: [mandatory] [single] This attribute specifies the duration until which the object or reservation is valid or until when the wait period will last Values: Kessens [Page 7] Draft RIDE Classes September 1997 Date is a UTC date. It's value is specified in the following format: YYYYMMDD [HH:MM:SS] description Analogous to the definition of this field in Contact class above. url Analogous to the definition of this field in Contact class above. contactreference Analogous to the definition of this field in Contact class above. countries Analogous to the definition of this field in Contact class above. created Analogous to the definition of this field in Contact class above. updated Analogous to the definition of this field in Contact class above. aup Analogous to the definition of this field in Contact class above. registry Analogous to the definition of this field in Contact class above. Definition of Host class The Host class represents one DNS server that is responsible for one serving one or more zones. handle a aaaa fqdn contact Kessens [Page 8] Draft RIDE Classes September 1997 description url contactreference counties created updated aup registry handle: [mandatory] [single] This unique read-only attribute contains a unique identifier for this object. This attribute is generated in the CORE database. a: [mandatory] [multiple] This is a DNS (A) record for this hosts IP version 4 IP Address. More than one A record should be supported for multi-homed IPv4 hosts. aaaa: [mandatory] [multiple] This attribute contains the IP version 6 IP address this host. More than one AAAA record should be supported for multi-homed IPv6 hosts. fqdn: [mandatory] [single] This attribute contains the Fully Qualified Domain Name of this host. A dot (.) is not required on the end of a FQDN. This field is required. contact: [mandatory] [single] This is a multivalued attribute and must contain a valid Contact's Handle. description Analogous to the definition of this field in Contact class above. url Analogous to the definition of this field in Contact class above. contactreference Analogous to the definition of this field in Contact class above. Kessens [Page 9] Draft RIDE Classes September 1997 countries Analogous to the definition of this field in Contact class above. created Analogous to the definition of this field in Contact class above. updated Analogous to the definition of this field in Contact class above. aup Analogous to the definition of this field in Contact class above. registry Analogous to the definition of this field in Contact class above. Definition of IPregistration class The IPregistration class describes to whom a certain range of IP addresses is allocated or assigned, together with technical and administrative data to facilitate the network operatrs and administrators. The class can use any existing IP version. IPaddressrange IPstatus gooduntil netname reversenameservers description url contactreference countries created updated aup registry IPaddressrange: [mandatory] [single] This attribute defines the IP address range for which the allocation or assignment is valid. The range is specified by using the smallest and largest IP address of the range. Kessens [Page 10] Draft RIDE Classes September 1997 IPstatus: [mandatory] [single] This attribute refers to the current CIDR status of the address range. Values: < PROVIDERINDEPENDANT | PROVIDERAGGREGRATEBALE | UNDEFINED > < ALLOCATION | ASSIGNMENT > gooduntil: [mandatory] [single] This attribute specifies the duration until which the object or reservation is valid or until when the wait period will last Values: Date is a UTC date. It's value is specified in the following format: YYYYMMDD [HH:MM:SS] netname: [mandatory] [single] This attribute is the name of the network associated with this object. reversenameservers: [mandatory] [multiple] This attribute contains the set of nameserver(s) that are authoritative for the reverse resolution of the address range. Nameservers are specified by using their fully qualified domain name. description Analogous to the definition of this field in Contact class above. url Analogous to the definition of this field in Contact class above. contactreference Analogous to the definition of this field in Contact class above. Kessens [Page 11] Draft RIDE Classes September 1997 countries Analogous to the definition of this field in Contact class above. created Analogous to the definition of this field in Contact class above. updated Analogous to the definition of this field in Contact class above. aup Analogous to the definition of this field in Contact class above. registry Analogous to the definition of this field in Contact class above. The route, aut-num, as-set, rs-set, inet-rtr and dictionary classes: Those classes are currently being defined by the RPS IETF working group. Since there only exist two different definitions in the world, RIPE181 [2] and RPSL, and RIPE181 is currently being substituted by RPSL, we will use the RPSL definitions as the standard and will only describe the differences between RIDE and the RPSL representation. The only exception in this is the aut-num object which has a different format in the InterNIC registry, however, this is merely a matter of naming conventions. Security considerations There are no security implications. The authentication/authorization mechanisms are a description of the systems that several Internet registries currently use, there is no claim made in this document that they are actually secure or safe. This is an issue that should be addressed by the individual registries. Furthermore, every user that registers information in an Internet registry should be warned that their information is globally visible and could be abused if no proper care is taken on which information one actually wanted to be visible. Acknowledgments Kessens [Page 12] Draft RIDE Classes September 1997 We would like to thank Masaya Nakayama, and everybody that contributed to the work of the RIDE IETF working group in general, for their various comments and suggestions. Appendix A: formal description in IDL This section will be filled in by Rick Wesson when the classes are more ironed out. Appendix B: yacc parser This section will be filled in by David Kessens when the classes are more ironed out. References [1] C. Alaettinoglu et. al., draft-ietf-rps-rpsl-03.txt, July 1997. [2] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, and J. Yu, "Representation of IP Routing Policies in a Routing Registry", ripe-181, RIPE NCC, Amsterdam, Netherlands, October 1994. Author's Address: David Kessens, ISI 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292-6695 USA davidk@ISI.EDU Rick H. Wesson Organic Online, Inc 510 3rd St. Suite 540 San Francisco, CA 94107 USA rick@organic.com Dhaval Shah Cisco Systems Inc. 170, W. Tasman Drive Kessens [Page 13] Draft RIDE Classes September 1997 San Jose, CA 95134-1706 USA dhaval@cisco.com --- Kessens [Page 14]